TÉCNICAS DE DESARROLLO DE SOFTWARE ÁGIL

Para más imágenes generadas con IA → Sign in

☆ majo
ÍNDICE:
UNIDAD 1 4
HISTORIA DE LA AGILIDAD 5
LÍNEA DE TIEMPO DE LA AGILIDAD 6
HOW TO FAIL WITH AGILE 8
Resumen: 8
Heart Of Agile 9
COLLABORATE 12
DELIVER 14
REFLECT 16
IMPROVE 17
Crystal Clear 19
PROPERTIES: 19
AGILE MODELING 22
Movimiento #NoEstimates 27
Los puntos de la historia pueden ser peligrosos.. 28
10 nuevos principios para el desarrollo de Software propuestos por elVascoDuarte 29
HACER FUNCIONAR #NoEstimates EN AMBIENTES DONDE DEBO DAR
ESTIMACIONES 31
Tácticas para aplicar #NoEstimates 31
MONEY FOR NOTHING 32
CHANGE FOR FREE 32
Escalando Agilidad 32
Retos a la hora de escalar agilidad, que aspectos tener en cuenta: 34
SAFe - Scaled Agile Framework 36
TUENTI 37
SPOTIFY 37
Agile Coaching 43
¿Cómo comenzamos? Método PrOpER 49

UNIDAD 2 50
Teoria X y Teoria Y - Modelo de motivación (de McGregor,Cutcher-Gershenfeld) 51
Management 1.0 52
Management 2.0 52
PEOPLEWARE 53
Management 3.0 53
MOTIVACIÓN INTERNA Vs MOTIVACIÓN EXTERNA 53
FACTORES DE MOTIVACIÓN 54
Otras Prácticas Propuestas por el Management 3.0 60
Speed Dating 61
NikoNiko Calendar 61
 Happiness Door 62
TShirt Test 62
MERIT MONEY 63
LAS 6 REGLAS DE LAS RECOMPENSAS: 68
Entornos de Productividad 68
¿Hasta qué punto el entorno físico influye en la obtención de resultados? 68
Técnicas de manejo del tiempo 69
Desperdicios que Frenan la Productividad 71
→ EL IMPACTO DE LA NO-CALIDAD 76

EQUIPOS 77
MULTIFUNCIONALIDAD 77
→ Team Barometer 79
→ MODELO TUCKMAN 80
EQUIPOS AUTOORGANIZADOS 83
Auto-organizado vs Auto-gestionado 84
Modelos de Liderazgo y Auto-Organización 84
Equipo Clasico → Modelo “Control y Mando” 84
Caracterización de Liderazgos: 85
TOMA DE DECISIONES 89
En cuanto a la idea de que TODO el equipo participa en TODAS las decisiones:
Delegation Boards: 89
preguntas autoestudio - agiles
Agiles - Preguntas Autoestudio (version majo y enzo )
kahoots - agiles
 UNIDAD 1

La agilidad ha cambiado para siempre a:

➔ La ingeniería de Software
➔ La gestión de Proyectos
➔ La relación con operaciones
➔ Los negocios
Las organizaciones

La agilidad vino a cambiar la manera en que hacemos las cosas.

¿Por qué pasó esto? o como se dieron cuenta que es necesario? Cuando la manera
tradicional de hacer las cosas empezo a afectar al negocio, pérdidas económicas.No
podemos estar 1 año desarrollando ni dos meses para sacar una aplicación.
profeMariano: Si no agilizamos nos come el mercado

La propuesta de las prácticas ágiles se adapta mejor a las nuevas necesidades de la

industria, y en el último tiempo la mayoría de las empresas lo aplica a sus equipos de
desarrollo. Entre el 2015-2019 se mantuvo superior a 95% el numero de empresas que
reportan usar agilidad en desarrollo.
Pero estas prácticas no solo son útiles para las empresas del ámbito de software, y cada
vez se propagan más a otro tipo de organizaciones y otros tipos de equipos.Podemos decir
que la agilidad está escalando, cada vez se la aplica en más áreas, que no son de desarrollo.

Cómo medir si me esta funcionando aplicar agilidad?

outcomes >>>> outputs
Buenas medidas son la satisfacción del cliente, el aporte al negocio, working sw.
El valor
La calidad en lo que realizó → en agilidad la calidad no se negocia → desde el inicio el
equipo debe comprometerse a trabajar con calidad
Para lograr esto necesitamos de equipos maduros técnicamente. No puedo tener un equipo
ágil que no conozca buenas practicas de programacion, patrones, practicas, tecnicas y
herramientas

La agilidad en sí misma aplica agilidad → mejora continua en sus propios procesos → está
en constante evolución → seguimos buscando mejores maneras de hacer las cosas .
Agile todavía es un campo nuevo
“We are still in the infancy of naming what is really happening on software development
projects. “ -Alistair Cockburn
la agilidad está en pañales dice

HISTORIA DE LA AGILIDAD

La agilidad no aparece de la nada con la firma del Manifiesto Ágil en 2001. A Partir de
buscar una manera distinta de hacer las cosas a la hora de desarrollar SW, tratando de
solucionar las desventajas de otras metodologías más clásicas, surgen varias prácticas.
Luego van notando como tienen muchos puntos en común entre ellas, por lo que las
agrupan en un solo concepto Metodologías Ágiles. Estas ideas siguieron evolucionando, e
incluso ya no se considera apropiado usar el nombre de metodología, porque ya no lo
vemos como un conjunto de pasos que indican qué, cómo, quién y cuándo, sino más como
un conjunto de principios y valores, y prácticas,técnicas y herramientas sugeridas para
implementarlos.
LÍNEA DE TIEMPO DE LA AGILIDAD
En la década del 60-70 las ideas con las que se desarrollaban SW eran mucho más rígidas
ya que tomaron influencias de metodologías de desarrollo de productos físicos →
Inicialmente visión influenciadas por las ideas del área industrial (arquitectura, construcción
de HW, construcción de productos fijos).

Pero como sabemos, no es lo mismo construir HW que SW, un producto intangible con un
gran componente intelectual en su desarrollo.
→ Conferencias de la OTAN del 68 → surge la ing de sw
→ pero Ing de SW no puede ser igual a Ing de HW → no podemos desarrollar sw de
la manera que construyo una casa

Década del 70 → surge ciclos cascada - metodologías clásicas → antepone procesos a

personas → modelo predictivo → cumplir plan por sobre todo
taylorismo → procesos antes que personas → lo opuesto a agil
..85 → Surgen prácticas como DoD --> comienzan las influencias de anteponer
personas a procesos - iteraciones - importancia del componente humano
Las 3 metodologías más importantes en los 80 y los 90

Década del 90 → aquellos que no hacen actividades manuales, tienen otras necesidades
y características
→ Influencias de Peter Drucker, trabajadores del conocimiento
No podemos volver al Taylorismo

→ darle importancia a las personas dentro de los equipos de trabajo.

Además crece en esta época una gran comunidad sobre buenas prácticas y patrones de
diseño de software. Donde también ocurría que las personas más presentes en esta
comunidad fueron los mismos que luego fundaron la Agilidad, partiendo con estas
bases de software con un diseño de calidad, modular y reutilizable.

91 → OMT (Object-Modeling Technique) → metodología para el desarrollo OO→

objetivos: Comunicación con los clientes, visualización y reducir la complejidad →
metodológica que inspiró el lenguaje UML
→ los modelos siempre seran herramientas de comunicación, si bien ya no se implementa
cada diagrama propuesto en UML, si alguno sirve para entender nuestro producto,
bienvenido sea

Surgen un conjunto de frameworks -no metodologías- para resaltar diferencia con

metodologías clásicas y estrictas
94 → modelo de pensamiento adaptativo sw developer → ADAD SOF DEV -
95 → DSDM
→ SCRUM → desarrollo scrum INTEGRADOR - ISW
→ CRYSTAL → Crystal Clear -Alistair Cockburn
97 → FDD - Feature Driven Development
99 → XP

Crece esta corriente de ideas, que compartían una serie de principios, y en un intento de
agruparlas, en 2001 surge el manifiesto ágil.
forma de ver cómo crear productos de carácter intelectual

Historia ING DE SW → para entender cómo llegamos a agilidad

HOW TO FAIL WITH AGILE
How To Fail With AGILE.pdf

Heart Of Agile
https://heartofagile.com/ - Alistair Cockburn Website

Desde la firma del Manifiesto Ágil en 2001, aumentó cada vez más la cantidad de
organizaciones y equipos usando frameworks ágiles, mayormente Scrum. Como pasa
siempre, en algún momento el contexto cambia, y las necesidades de los equipos y las
demandas del negocio también cambian. Entonces aplicar la Guía de Scrum al pie de la letra
ya no es lo mejor, surgen así nuevas prácticas, técnicas y frameworks, y aún más, la idea de
combinar prácticas y frameworks y tomar lo que nos sirva de cada una, lo que se conoce
como cherry picking.

Dentro de las nuevas propuestas de la agilidad, una muy presente, es Heart Of Agile de
Alistair Cockburn. Que no pretende ser un framework ágil, sino más bien una herramienta
que resuma la esencia de la agilidad. Que nos sirva de guía para mantener el enfoque de los
pilares de la agilidad.
No me dice seguí tal y tal práctica, pero las prácticas o técnicas que implemente, o en
general como trabajamos, debe tener implícita y/o explícitamente estos cuatro factores.

Nace de una disconformidad de muchos en el mundo ágil, que la agilidad está

“sobre-decorada”, lo que comenzó con un manifiesto de solo 4 valores y 12 principios,
ahora es un conjunto de frameworks, roles, artefactos y ceremonias a seguir.
(alejándose bastante de la concepción de que no sea una rígida metodología, no?
Contradiciendo el propósito de la agilidad)

Alastair empieza a notar que se están perdiendo las nociones básicas que propone la
agilidad, siendo por ejemplo ahora un Scrum Master aquel que cumple una larga y rígida
lista de requisitos de un caro examen de certificación → propone volver a las raíces de
la agilidad → simplificar → basarnos en valores bien establecidos
(collaborate-deliver-reflect-improve)

Para poder hacer esto, debemos entender el POR QUE de las cosas → no puedo hacer
cherry picking si no conozco todas las técnicas, si no entiendo el por que de cada una

Para explicar está propuesta de simplificar, Alistair plantea un modelo de aprendizaje

basado en 3 niveles y un último estadio llamado kokoro

model of learning acquisition → learning stage:

Identifica 3 niveles de aprendizaje:
SHU - HA - RI
Este es un concepto propio de las artes marciales japonesas, y describe las etapas del
aprendizaje hasta la maestría. que se definen de la siguiente manera

shu (守?): "Proteger", "obedecer" — sabiduría tradicional — técnicas fundamentales,

heurística, proverbios.

ha (破?): "desapego", "desprendimiento" — ruptura con la tradición - desapego respecto

a las ilusiones.

ri (離?): "Dejar", "separar", "trascender" — no se aplican técnicas ni proverbios, todos

los movimientos son naturales; convertirse en uno con el espíritu sin aferrarse a las
formas; transcender lo puramente físico.

Bajado esto a la propuesta de HoA el corazon de un gil:

Se presentan de manera incremental:

SHU → follow
learn one technique
→ Siempre la primera forma de aprender algo es aprender una receta. El problema de
quedarse en la receta es no poder salir de eso que puede mejorar
quedarse siempre en este nivel → the shu box problem

HA → detach
collect techniques → ya manejo una técnica → aprendo otras
→ aprende y domina la técnica. → domino una técnica soy por ej sha level en scrum -_>
voy aprendiendo otras prácticas
 RI → leave
invent and blend techniques → hacen algo distinto cada vez, sin notarlo, ya tienen
incorporada la esencia de la solución → what did you do? I can't tell you
→ cuando se tiene muchos años de experiencia, o en gestión de proyectos, cada vez q
trabaja en uno nuevo lo hace de manera distinta → no necesito ir a un libro y seguir
cierta metodología → solo lo hacen y sin explicar el por qué

RI y SHU son opuestos

Shu → quiere una receta → nunca es una técnica o solución óptima
Ri → lo hacen distinto cada vez

en agilidad ,sobre todo, no me puedo quedar en shu, se supone que estoy en un proceso
de mejora continua → paso a HA → recolectó distintas técnicas
luego llegó a Ri donde hago las cosas sin pensar como (porque ya soy re caPO)

¿Qué hay después de RI?

otro término en el que se basa es el → kokoro → no tiene que ser tan complicado, just
learn the basics
kokoro represents the teaching stage of the advanced practitioner
kokoro → just master the basics > Miyagi loco
Si no puedo hacer ya algo complicado, descomponer el problema, primero practicó las
partes básicas. Para poder avanzar en las etapas, comienzo manejando bien las bases,
lo esencial de cada tema.
El que enseña agilidad debería buscar identificar las cuestione básicas elementales
esenciales y transmitir eso al shu o ha level

SHU-HA-RI-kokoro →Hay un pasaje progresivo por estos estadios, va incrementando

con la experiencia → hay una versión para beginners y luego ciertas técnicas para
mejorar cada parte
→ comenzamos con lo simple (shu-aprender una técnica) , y se va complicando a
medida que aprendemos mas y mas técnicas (ha-collect techniques), la complejidad
sube aún más al querer combinarlas, para lo que es necesario un entendimiento más
profundo (ri- invent and blend). Y finalmente, todo se vuelve más simple, tenemos claras
las bases y lo esencial, aca llegan los “kokoro-level” teacher. La solución más simple no
es la más fácil, al contrario, requiere un alto nivel de maestría.

The Heart of Agile

Alastair se basa en estos cuatro pilares para explicar la esencia de la agilidad, el kokoro
de la aglidad:
● Collaborate. Colaborar
● Deliver. Entregar
● Reflect. Reflexionar
● Improve. Mejorar

The “shu-ha-ri” concept of skill progression applies to each of the four, and to each of the
sub-categories under them

SHU-LEVEL EXPANSION OF THE HEART OF AGILE

----------------------COLLABORATE
You may not want to but you now how…
Motivation and collaboration - trust → esenciales, necesarios para la colaboración a
shu-level
Para explicar esto tambien mencionamos la teoría X y la teoría Y (tema desarrollado en
la unidad 2)

Para mejorar la colaboración → incrementar la confianza

relaciona a un líder con anfitrión de una fiesta → menciona el personaje del guest
leader (ultimo tema desarrollado en la unidad 2) → pero qué pasa si los líderes fueran
los invitados?
Shu-level Tool for Improving Collaboration

----------------------DELIVER
Es un aspecto más técnico, más del mundo del desarrollo → entregar de a
pedacitos todo el tiempo → small and frequent releases → deliver incrementally, early
and often

Acá hablamos de todo el proceso de entrega. Este tiene factores internos y externos. En
la parte interna, tomando influencias de Lean Production, Lean Manufacturing,Lean
Kanban, queue management, bottlenecks, work-in-progress limits
En cuanto a lo externo, habla de diferenciar en entregar para generar ingresos
directamente, o entregar para aprender.
Deliver just to learn → para entender que quiere el mercado, y tambien para aprender a
trabajar juntos y encontrar errores rápidamente (fail fast learn faster)

Retomando a los factores externos, y a lo que sería como el queue management, pero
de decisiones:
la base de una organización es tomar decisiones. Y todos están esperando por la
decisión que tiene que tomar alguien más para comenzar su trabajo.
diagrama de dependencia de decisiones → se ve como el flujo de un linea de producción
Lean Startup -2010-2011-
modern agile project management → consideran al desarrollo de sw ágil muy
lento, mientras más inventario en movimiento tengo mas tardamos en tomar las
decisiones y en pasarlas a quien las necesite

Por eso en agilidad hablamos de flujos continuos, en cantidades pequeñas, pequeños

incrementos
Make the project “self-funding” as soon as possible → el dinero que entra a un proyecto
es suficiente para financiar lo que se está desarrollando en el momento
Entregar para aprender (“Pagar para aprender”)
este ta mal, el de abajo no jeje

BIG-BANG → hago todo y después lo integró y entrego (claramente una mala idea).
Claramente es mejor hacer early and frequent releases → hay una parte o sección en el
proyecto (no fase) donde intentamos cuidarnos más de los riesgos e intentamos
reducirlos
la pendiente empinada es enfocada en valor y asegurar nuestros basics
La cola es estable, podemos escalar de atrás para adelante.

----------------------REFLECT
Antes de querer hacer algo, detenernos a reflexionar en serio, cual es el problema y que
lo está causando. PATITO AMARILLO DE LOS PROGRAMADORES
La reflexión incluye dos partes
→ las razones subjetivas, emocionales → sobre el equipo, los procesos que
usamos
→ info objetiva → examinar los datos → datos sobre el producto y sobre la
reacción de los usuarios/clientes
HAY QUE PRESTAR ATENCIÓN Y DARSE CUENTA DE LAS COSAS ~notice

----------------------IMPROVE
mejora reflexiva → inspeccionar y adaptar
reflect on everything, reflect on the reflect
Una vez identificado los problemas y posibles causas en la reflexión, definir que
acciones tomamos para mejorar.
Para esto debemos hacer cambios, no podemos estar seguros de que funcionaran, hay
que experimentar
Esto no es una metodología ni un framework → herramienta de enfoque → una
manera de ver la filosofía ágil → cada proceso, equipo, tarea debe tener implícito estos 4
pilares, es un conjunto de recordatorios.
En vez de escalar procesos, de escalar scrum → propone centrarnos en estos 4 pilares
básicos → para poder cambiar estructuras, debemos cambiar el comportamiento

● Independent of anything else going on, how will you increase collaboration?
● Accounting for everything else going on, how will you increase trial and actual
deliveries to consumers?
● How will you get people to pause and reflect on what’s happening to and around
them?
● What experiments will your people perform at different levels in the organization
to make small improvements?
People can’t hide behind vocabulary or job title shuffles to answer these questions.
There is nothing but attitude and behavior to improve, which is what we want.
Agile 2
https://agile2.net/agile-2-values-en-espanol/
Orígenes de la agilidad:
Previo a la firma del manifiesto, había muchas más prácticas además de scrum y xp que
tenían componentes ágiles(influencias, valores, principios). Si bien hoy se las considera más
antiguas, muchas mencionan prácticas interesantes para incorporar.

Crystal Clear
-Alistair Cockburn
Metodología de los principios de agilidad (pre-manifesto)

no tenemos restricciones presupuestarias o de requisitos extraños →

practicas que adoptan los equipos que realizan productos de manera exitosa
¿Qué hacen otros equipos para ser exitosos?

PROPERTIES:
Frequent Delivery → feedback critico rapido → asegurarle al usuario q se
comprenden bien sus requisitos → mantener enfocados a los trabajadores
xp? no se si refiere a entrega cont e integración continua

Reflective Improvement → retrospectivas (en scrum)

Osmotic Communication → estar en el mismo ambiente → por ej en

slack,discord etc → llamada por zoom no es comunicación osmótica → slack es
herramienta que puede favorecer la comunicación osmótica.

Personal Safety → la gente tiene que tener la tranquilidad para poder expresarse
sin problemas → is an early stage towards trust

We mariano
 Focus profeta yendo muy rápido → mantener el enfoque → se logra cuando hay
trabajo por ambas partes (poresonosgustaestamateria)

Easy access to experts

TECNICAS Y ESTRATEGIAS:

STRATEGY:
#1 Exploratory 360° → documento expresando como agrega valor al client

#2 Early Victory → organizar estrategia del proyecto para intentar conseguir una quick
win → a partir de ahí estar motivados para completar el resto
#3 Walking Skeleton → profe lo suele usar en despliegue de clouds → no significa tener
todo desarrollado, tener un esqueleto completo

Una buena idea para el comienzo de un proyecto → Planear una early victory y
desarrollar un walking skeleton → así ya tenemos una base de la arquitectura
funcionando

#4 Incremental Re Architecture → Ir trabajando con refactorizaciones sobre la

arquitectura existente → Por que? hoy hay muchas opciones de arquitectura.

#5 Information Radiator → Info para enfocar a las personas que trabajan y motivar
(Llegar al millón de usuarios)
No se toman esos temas en examen → que temas?

AGILE MODELING
-Scott Ambler
Es una metodología basada en prácticas para el modelado efectivo y la documentación
de sistemas basados en SW.

No lo quieren tanto los agiles → es mas similar a metodologías clásicas

→ útil si trabajamos en entornos más burocráticos, e intentamos

darle un enfoque ágil . www.agilemodeling.com
cascadita con olor a scrum
uno tiene que poder identificar los conceptos y características básicas del problema
para decidir qué prácticas usar .
MODEL WITH A PURPOSE → no es necesario , o incluso es malo, modelar todo → solo
modelar aquello que me aporta valor . No hablamos de NO modelar , sino de crear solo
aquellos modelos que aporten valor . si necesito un prototipo para q el cliente vea si es
como a él le gusta? modelo una interfaz ponelo → un lay out
una abstracción más simple de la realidad ahr e

si modelo, pero solo lo q aporta valor

WORKING SOFTWARE IS YOUR PRIMARY GOAL →

--> mock a mano alzada justo antes de desarrollarlo

 --> seguir usando estos modelos
si aportan valor
los detalles sintácticos no son fundamentales en el mundo real.

totalemnte de acuerdo con verobollati

toy un pco perdida → q hablaron a solo está hablando de que ya da igual modelar
exactamente correcto me gusta la práctica esta igual modelstorming

Iteration Modeling
Modelar conmayor nivel de detalle aquellas US que tengan más alta prioridad en el
backlog

Document Late
 lA documentacion que si o si debe realizarse por razones burocraticas . we esta
adentro de un tornado mariano

no hagas toda la documentación pedida al inicio , solo lo mínimo indispensable

sw de dispositivos → necesitan de documentación → siempre vienen con diagrama de
interacciones → no comenzamos con todo el modelado

Con respecto a esfuerzo a hacer y el valor que aporta el documento → llega un

momento en el q modelo deja de aportar mas valor y se lo sigue decorando →
agregamos detalles que no aportan valor
tratar de identificar el punto en que esfuerzo y valor estén en su punto mas alto
resumen clase 23/8.pdf → Crystal y Agile Modeling
Movimiento #NoEstimates

NoEstimates-book-Chapter-1-We-suck-at-estimation.pdf

Estimar → dar una aproximación o predicción de la duración o costo de un proyecto →

tenemos una referencia de tiempo para dar feedback
Actualmente se empezó a notar muchas desventajas de trabajar con estimaciones, y cómo
esta puede ser vista como desperdicio.
estimate better.. as if estimating better would make the team work faster or the project end on
time

Creemos que una vez que asignamos un “número” ya sabemos cuánto tardaremos en
entregar → y surgen problemas al creer en las estimaciones más que en los datos de lo
que se estaba entregando
Believing in estimates is worse than believing in unicorns

El mejor escenario es alcanzar la estimación, osea no perder más dinero del que
pensaba gastar. No ayuda a mejorar o aportar más valor a las estimaciones.

Cumplir con la estimación NO es valor entregado → entregar algo al mercado es valor,

obtener feedback es valor.
Trabajamos para entregar valor, no para completar tareas
Solo podemos medir y recibir feedback de cosas que ya están en el mercado

No Estimates → surge de un proceso de mejora continua → eliminar todo el desperdicio

que se produce al estimar, de manera ágil o no.

Analizamos como equipo qué cosas nos aportan valor y que generan desperdicio.
desperdicio → aquello que consume tiempo pero no aporta valor
Si en cada sprint medimos la productividad o avance a partir de working software, y no
velocidad o puntos de historia completados.
Como nuestra medida de valor es working sw → la productividad se mide en working
sw → el tiempo que toma la estimación comienza a ser visto como un desperdicio.
desarrollo → ese proceso pasalo a la planning - definir historias del mismo tamaño

La idea está en diseñar el proyecto de manera que las cosas se hagan con calidad y
bien, solo así no perderemos tiempo, no es llegar a cumplir las estimaciones es cómo
podemos trabajar cada vez de mejor manera para que se termine cada vez más rápido.
Al dar una estimación, una razón entre costo y
duración, no se puede contemplar las complicaciones
accidentales.
essential → lo que comprende el problema en si para
resolverlo - los aspectos técnicos-
accidental → no somos tan buenos en nuestro trabajo como creemos - por algo hay
testing -

Cuando estudiamos estimación, también decimos que aprendemos y mejoramos con la

experiencia.

Pero hay que tener en cuenta que:

Al comparar una historia de hoy con una historia del pasado, estamos comparando una
historia en el contexto del sistema ahora que es totalmente diferente del contexto de
ese sistema en el pasado, por lo que dos puntos historia hoy no es el mismo que los
dos puntos de la historia antes. Min20
Además puede hacernos perder mucho tiempo:
En las primeras estimaciones cuesta mucho ponerse de acuerdo. El tiempo que
estoy en la planning poniendo puntos de historia. A veces todo este proceso me hace
perder tiempo. Nos saca tiempo del sprint.

Estimar cuánto nos tomará realizar una US, pero no cuánto tiempo pasará hasta que
empiece a realizarse.
queue time → measure the life of the average backlog

Los puntos historia pueden ser peligrosos..

El proceso de asignar una cierta cantidad de puntos a una US puede ser visto
como desperdicio
- El tiempo que gasto en una sesión de planning poker
- Las primeras estimaciones suelen fallar
- Podemos asignar mal los puntos si no entendemos las US
- Confiamos más en la complejidad asignada que en el trabajo que
sabemos/podemos hacer
- solo recordamos puntos historia, y no mantenemos registros de
cuántas US se terminaron en el sprint
- plannings muy largos
Woody Zuill y Neil Killick parten de la pregunta si vale la pena estimar cuando no se lo
que tengo que hacer. → Cómo podemos estimar cuando todavía no sabemos o
entendemos la solución
Y si hago actividades de análisis pre-planning? aún más desperdicio
dual-track discovery → cuando tengo US muy complejas - el po al definirlas muchas
veces asigno una persona del equipo para que vaya entendiendo las historias - pero
ese miembro está perdiendo tiempo de

El tiempo que pierdo estimando mejor invertirlo en entender mejor las US o aprender
a hacer US del mismo tamaño asi no pierdo tiempo estimando.

Al final el objetivo es determinar cuántas historias como máximo pueden entrar en un sprint, y
que el equipo pueda trabajar a una velocidad sostenida.

10 nuevos principios para el desarrollo de Software propuestos por

elVascoDuarte
Principio #1
Trust your process or change your process.
Confía en el proceso, o cambia tu proceso
Principio #2
Shorten the feedback cycle
Acorta el ciclo del feedback (mas pequeñas entregas asi obtener mas feedback)
Principio #3
Believe the data not the estimates
Confía en los datos no en las estimaciones
Principio #4
Use alternatives to Estimate-driven decision making
Usar alternativas a la toma de decisiones basadas en estimaciones
Principio #5
Test for value first, then test for functionality.
Probar el valor primero, después probar la funcionalidad
Principio #6
Estimation is waste, reduce its impact on your business
Estimar es desperdicio, debes reducir su impacto en tu negocio
Principio #7
Measure progress only with validated, running software
Medir progreso solo con software funcionando y validado
Principio #8
The system where you work has predictable outputs, learn to understand the system.
El sistema en el que trabajas tiene salidas predecibles, aprende a entender tu sistema
Principio #9
Don't bet your company on poor track records methods, use methods with a proven
track record. aka: Hope is a bad management strategy
No apuestes tu compañía jugando a los tazos, utiliza métodos que tengan resultados
probados. Ak47 - La esperanza es una mala estrategia de gestión
Principio #10
The transformation starts with you…
El cambio empieza con vos <3 -Macri
Principio #11
What if.. There is no PROJECT?
ke… pero …. y Si no hay PROYECTO ???? NANI??? EL GATOOOOOO :’(

El camino del producto lo voy construyendo → no tenemos que llamarlo proyecto →

siempre sabemos cuando empieza pero no cuando termina → las necesidades las voy
descubriendo

QUÉ ASPECTOS TENER EN CUENTA PARA PODER APLICAR NO ESTIMATES?

★ Es necesaria la confianza con el cliente - se puede dar si estamos en un ambiente de

confianza realmente - se implementa mucho en equipos que desarrollen para sí
mismos, su propia empresa.--> además de contar con equipos pasivos y maduros de
40 con lugar.
★ sw de calidad → saber claramente que hay que hacer - hacia dónde quiero llegar
→ y en que tengo que trabajar como equipo
Si todos sabemos a dónde queremos ir no hace falta centrarnos en cuánto tiempo nos
va a llevar cada una de las cosas. Sino condiciono el proyecto a la estimación

Para construir buen software necesitamos solo una visión clara, un propósito
compartido, objetivos de alto nivel, y no el detalle de cómo vamos a lograrlos

#NoEstimates no significa que las estimaciones sean malas, sino que no siempre son
necesarias. -Woody Zuill

Si no estimamos… ¿Cómo medimos el progreso? ¿Cómo tenemos una referencia de si

estamos rindiendo como equipo?
Un punto medio seria, no medir la estimación a partir de esfuerzo, sino a partir del output →
working sw
desventajas → puedo terminar eligiendo las US más pequeñas para ser más
“productivo”
próximo paso → hacer las US todas del mismo tamaño → si todas son iguales no puedo
elegir las más fáciles. → realmente puedo elegir las US que me aporten mayor valor →
tengo un backlog ordenado realmente por valor
Al no atarme a la estimación → puedo cambiar los requisitos cuando quiera
What we need to produce is more value, not more software

More software
= more costs
More value = more return on your time

Mida el progreso solo con running sw validado

HACER FUNCIONAR #NoEstimates EN AMBIENTES DONDE DEBO DAR ESTIMACIONES

★ Intentar que las US tengan el mismo tamaño y similares → ya no es necesario
analizar la complejidad de las US → clave
★ Si no puedo llegar a no estimar → reducir tiempo de estimaciones → cambiar puntos
historia por contar la cantidad de US → esto lo logro aplicando el punto anterior
primero
 ★ comenzar con proyectos de poca inversión. entrega Working SW siempre, de a
poquito
★ Financia un prototipo que entregue ws, luego usa modelos para hacer predicciones
al final estimar es una predicción
Para no atarme a una estimación que capaz no voy a poder cumplir → prototipo que
entregue una funcionalidad y en base al feedback, eso uso de modelo de proyecciones.
★ Convierte las relaciones contractuales a partnerships → empresas pequeñas donde
uno pone la inversión y otro hace el trabajo → en vez de comercializar proyectos -
comercializa productos. En el proyecto tengo un cliente más definido - en el producto
no
★ Modelos de comercialización cloud → en vez de venderme el producto o proyecto
vendo el servicio (alexa)
Indispensable aca el punto anterior de confi

Tácticas para aplicar #NoEstimates

★ Trabajar bajo demanda → en vez de dar estimaciones pedir presupuestos → se
venden las horas ocupadas → cliente paga por funcionalidad → se paga el esfuerzo
invertido → trabajo terminado
anza con el cliente o que sea un proyecto interno a la empresa

Y esto cómo se vende?

★ Scrum propone una serie de cláusulas en los contratos → NO mas contrato “llave en
mano”
○ MONEY FOR NOTHING
→ Si en algún momento el cliente se da cuenta que lo que estoy construyendo no es lo que
quiere, cambiaron sus objetivos o requisitos → puede cancelar el proyecto, Para eso el
cliente me paga el 20% de lo que falta hacer (lo que ya estaba hecho hasta el momento ya
fue pagado) → la ventaja es que el cliente no tiene que pagar todo el proyecto y como
empresa no perdemos tanto ( lo que si completamos se pagó al 100%)
○ CHANGE FOR FREE
→ Si el cliente quiere hacer un cambio de algo que pidió y ahora ya no necesita → permitir al
cliente quitar esa US que no quiere, pero a cambio el equipo puede quitar una del mismo
tamaño.
Más recientemente en el movimiento, ya no se piensa q si o si hay q saber

Escalando Agilidad

Escalar agilidad → llevar la agilidad a toda la empresa → también lo conocemos como

transformación ágil

Para lograr la transformación ágil los valores y principios de la agilidad deben ser los
valores y principios de toda la organización → que la filosofía de la empresa sea la
filosofía ágil

En las practicas agiles siempre hablamos de equipos pequeños (7 +-2 personas), pero
que hacemos cuando tenemos empresas grandes?

-Ron Jeffries firmante manifiesto ágil

Que aspectos debería tener en cuenta para que mi empresa completa sea ágil? Analizar
el “nivel de ágil” que tenemos. La transformación tiene que ser paulatina, aplicar agilidad
de a poco, en pequeña escala → no puedo pensar en “ser ágil” si todavía no se trabajar
de manera ágil
Implementar agilidad primero en pequeños equipos, seguramente de desarrollo si los
tienen → luego ir por mas equipos → e intentar llegar a toda la empresa
Es indispensable que toda la empresa esté comprometida a hacer este cambio. → no
podemos pensar en “escalar agilidad” si todos en la empresa no entienden la agilidad, y
sus valores y principios
el equipo debe definir sus valores → demostrar que realmente son esos
Todo esto no funciona si no hay confianza, comunicacion y colaboracion

Para poder lograr realmente una TRANSFORMACIÓN ÁGIL → No me concentro en

frameworks, no intentó “escalar scrum” → enfocarse en la agilidad → en los principios y
valores → conjunto de principios que busca crear un producto que se adapte a las
necesidades, pensado en el cliente y con calidad por defecto
Los mejores exitos vinieron de aplicar diferentes prácticas adaptándolas a las
necesidades de cada empresa y equipo, no siguiendo frameworks como si fuera un
conjunto de reglas (recorda por que ya no usamos la palabra “metodología”) → esto
después lo vemos como CHERRY PICKING

AGILE == quick, dynamic, flexible, reactive , adaptable

Incluye mucha experimentación, probar y adaptar a la empresa las técnicas,

herramientas y prácticas que nos dan agilidad.
Lo que le funciona a un equipo puede no funcionarle a otro → voy probando, dejo lo que
funciona quitó lo que no → estoy en un constante proceso de mejora continua

entonces si podemos trabajar distinto, podemos igual coordinarnos, comunicarnos y

colaborar entre equipos? que nos une? Todos tenemos el mismo objetivo final (el exito
de la empresa, y demas cuestiones organizacionales que alli definan) y todos seguimos
los mismos valores y principios (los de la agilidad)

Que implica escalar la agilidad? → Coordinar la parte técnica y la gestión de equipos

parte técnica → herramientas, procesos, arquitectura del proyecto

gestión de equipos → Definir las reglas con las cuales nos vamos a relacionar dentro
del equipo y entre equipo, como nos dividimos, como nos comunicamos, etc
→ lo mas facil seria tener equipos independientes, donde el trabajo de uno no
afecta al de otro, o incluso trabajan para distintos clientes → no es difícil coordinar la
parte técnica , pero sí definir claramente cómo trabajamos internamente y entre equipos
→ Si son muchos equipos que trabajan en la misma aplicación → definir
claramente como nos dividimos y como nos comunicamos → por ej: Spotify
Si bien existen una serie de frameworks, intentamos no hablar de escalar SCRUM

No escalamos frameworks, escalamos los valores y principios ágiles

Retos a la hora de escalar agilidad, que aspectos tener en cuenta:

CONTEXTO DE LA EMPRESA

● ubicación → como estamos posicionados

● velocidad de entrega
○ velocidad de las necesidades del cliente → me ayuda a
elegir la práctica saber cada cuanto tengo que mostrarle
algo al cliente
○ velocidad del equipo → que capacidad de trabajo pueden
completar el equipo por unidad de tiempo
→ si me piden continuamente entregas cada un cierto periodo → me oriento mas por
SCRUM → time-boxing
→ si están constantemente cambiando requisitos y no tengo deadlines o no
importa mucho las fechas → KANBAN
● innovación → hacemos siempre lo mismo o estamos tratando de innovar en
nuestro producto o servicio?
● complejidad de lo que estoy trabajando
● defectos que tenemos → como reaccionamos ante el error y como tratamos a
quienes los cometen → “política del miedo” no funciona en agilidad → aprender
del error
● capacitación → el equipo debe poder realizar trabajo de calidad → para lo que
deben ser lo suficientemente maduros técnicamente (también es importante
enfocarnos en entrenar y mejorar las soft skills)

ESTRUCTURA DE LOS EQUIPOS

Como está definido el equipo → cuántos somos? ¿Cómo nos relacionamos? cómo nos
organizamos?
si tengo que dividir el equipo, como lo hago? para no perder la esencia del equipo y
poder ser ágiles
para definir nuestras reglas de comunicación todos debemos tener en claro la visión
estratégica

VISIÓN ESTRATÉGICA
Como empresa debemos tener una visión clara → TODOS debemos saber cuál es
nuestro objetivo, en que trabajamos, como lo hacemos y que estamos buscando →
sobre todo cuando son muchos equipos trabajando en una misma aplicación

PRIORIZACIÓN DEL PRODUCT BACKLOG

Definir una manera objetiva y clara para poder priorizar las necesidades, contando con
alguien que se encarga de hacer este trabajo
una vez que tengo el product backlog entero organizado → descomponer y generar un
product backlog para cada equipo → y luego el PO del equipo vuelve a priorizar su PB

La gestión del product backlog es especialmente dificil al tener muchos equipos

trabajando sobre el mismo conjunto de necesidades. Tenemos que definir formas de
dividirnos y organizarnos

PLANIFICACIÓN DE RELEASES
Hay distintas herramientas para esto:
- Roadmaps
- Mapa de Historias de Usuario
GESTIÓN DE LAS RELEASES
- Integración y Entrega Continua → con todo lo que esto implique (sobre tod
Testing Automático, sino si solo tenemos un entorno que hace la build es mas
“compilacion continua” que integración )
FEEDBACK DE LOS CLIENTES/USUARIOS
Feedback constante de los clientes → dependiendo de la empresa
pueden ser internos (spotify) o externos (globant)
escuchar lo que el cliente me dice para ir ajustando → preciso de un
sistema de mejora continua
MEJORA CONTINUA + ELIMINAR IMPEDIMENTOS
Constantemente Analizar si la manera en la que estoy trabajando es la mejor en ese
momento, y cada cierto tiempo podemos redefinir nuestras reglas o prácticas:
- ¿El cliente está obteniendo lo que quiere?
- ¿Estamos teniendo nuestro máximo rendimiento?
- ¿El equipo está motivado?
- ¿somos productivos?
si algo no funciona → cambiarlo
eliminar impedimentos → siempre hay problemas,
COORDINAR EQUIPOS CRUZADOS

Existen frameworks y metodologías para escalar la agilidad → la mayoría son muy

burocráticos, con muchos pasos y reglas (no suena muy ágil no?) → no son muy
queridos...

SAFe - Scaled Agile Framework

White Paper - Achiving Business Agility with SAFe.pdf

Framework pesado y burocrático → hay muchos pasos a seguir y reglas a cumplir

CASOS DE EXITO DE TRANSFORMACIONES ÁGILES

TUENTI

SPOTIFY
SPOTIFY ENGINEERING CULTURE.pdf

Spotify nace como una empresa pequeña que desde el principio quiso aplicar agilidad.
→ nace como una empresa ágil
Definían tener una cultura basada en equipos y aplicaban el framework SCRUM. Como
sabemos la aplicación tuvo mucho éxito, por lo que la empresa creció mucho muy
rápido.

Cada vez tienen más equipos y algunas prácticas de scrum no ayudaban.

Rules are a good start, then break it when needed

Identificaron algo que no funcionaba, y decidieron cambiarlo, tenían que modificar la

forma en la que se organizaban.Volvieron opcionales las prácticas, y adaptables.

Decidieron enfocarse en la agilidad por sobre Scrum, los principios por sobre las
prácticas, y en cambiar la figura del líder a un “servant leader”. Quitaron el rol del Scrum
Masters y ahora los equipos se definen como squads.

PO en Spotify → Recoge las necesidades que surge en el mismo equipo, ya que no hay
clientes externos → el PO escucha a los clientes internos, y a los usuarios.
servant leader → siempre disponible viendo que necesita la organización, se equipara
mas con lo que después vamos a ver como “agile coach”
Cada squad es “responsable” de uno o mas sistemas que tratan necesidades
especificas. Pero si bien hablamos de squads autónomos, de igual manera estarán
alineados entre sí.Porque todos deben estar alineados a los objetivos de la empresa,
todos deben tener la misma visión, los mismos valores y principios. basándose sobre
todo en la colaboración.

Por más de que está presente el concepto de “code ownership”,

es mas desde un lado de la responsabilidad, ya que se basa en
un modelo open-source donde se incentiva la colaboración entre
los squads,que compartan su trabajo y conocimiento entre ellos
el código es de todos y todos tenemos que colaborar en que
tenga calidad
Esta autonomía tiene muchos beneficios como mejorar la velocidad y motivación del
equipo (personas motivadas son más productivas y hacen un mejor trabajo). Tienen la
libertad de elegir cómo quieren trabajar, no se les exige una tecnología o práctica en
particular, cada uno puede adaptar las prácticas o intentar innovar. Además como se
intenta que los squads estén comunicados entre sí, y compartiendo lo que hacen se
puede lograr la “cross-pollination”, donde van aprendiendo de ellos y porque al squad
A,B y C le funciono algo capaz el squad D también lo prueba. se logra la estandarización
de los equipos de una manera más natural, basada en la colaboración.

Spotify llegó a un momento donde tenían más de 50 equipos, por lo que debían mejorar
la estructuración de los mismos, no basta solo con los squads.
squads (ex equipo) → se encargan de características funcionales específicas dentro de
la aplicación
a su vez cada squad está en una tribu
tribu → conjunto de squads que se encargan de funcionalidades similares que forman
un componente más grande
a su vez en una tribu se pueden formar chapters, con miembros de distintos squads
chapter → Conjunto de personas de un mismo “rol” o area de especialidad, por ejemplo
los QA, DBA, PO, agile coach,etc → aquellos que cumplen la misma funcionalidad en un
squad
Tambien se da lo que se denominan “guilds” , donde intervienen personas de distintos
squads e incluso distintas tribus, es mas descontracturado.
Al hablar de squads autónomos estos deberían ser “lightly coupled but tightly aligned”,
ya mencionamos el aspecto de que todos estan alineados a los objetivos de la empresa,
pero que contempla que sea “lightly coupled”?

¿Cómo se logra que el squad sea independiente hasta

el despliegue? DESACOPLAR
Al trabajar todos en la misma aplicación necesitaban
desacoplarse para poder trabajar de manera
independiente
→ tener una buena arquitectura de
microservicios → mejora la escalabilidad
 → mucho testing
→ entregas pequeñas y frecuentes
antes cuando era monolítica → todas las funcionalidades y servicios en un mismo
código fuente → cada deploy tenía que ser de toda la aplicación → por lo que todos los
squads debian sincronizarse para tener una release

Ahora que cuentan con una Arquitectura desacoplada, tambien tienen el beneficio de
que si hay un error afecta solo a esa sección especifica que pertenezca no a toda la app.
Además de que permite hacer “roll outs” graduales de la app, canary releases.
 PLANIFICACIÓN Y GESTIÓN DE RELEASES EN SPOTIFY

Si bien cada equipo puede hacer su deploy de manera independiente, es necesario un

cierto grado de coordinación y sincronización entre los squads. Para lo que se definieron
los “Release Trains” y “Features Toggles”

Release Train → Itinerario de releases → normalmente cada 1 semana → todo lo que

estaba hasta el momento de la release “va al tren” de todo aquello que se va a entregar,
incluso van aquellas features no terminadas (pero estas utilizan los features toggles).
Las features no terminadas van al train de release, se integran, se testean, pero no se
entregan, sino que se les coloca una etiqueta de visibilidad por lo que quedan “ocultas”
a usuarios pero visibles para los responsables de la aplicación.
Feature toggle → Ocultan las features no terminadas, permiten testearlas por separado,
o analizar posibles errores de integración de manera temprana, además de que reduce el
número de branches activas. Podríamos pensar que esto es una manera de “deuda
técnica”, pero en realidad NO lo es, ya que no se entrega , se convierte en deuda técnica
cuando llega al cliente o usuario

De igual manera, siempre seguirán surgiendo nuevos impedimentos, por lo que

también debemos tener un sistema para evitarlos o solucionarlos.
Spotify no solo se basa en “bienvenido el cambio”, también el error →
Fail-Friendly-Enviroment → no hay “política del miedo”, está bien equivocarnos siempre
que podamos aprender y mejorar a partir de eso → mejorar el proceso que llevo al error,
no solo arreglar el producto

Continuous Improvement Culture

Proponen algunas practicas para esto como las improvement boards

además de prácticas que ya conocemos como las reviews o retros.

Es importante lograr definir claramente el problema y a donde queremos llegar
tienen el concepto de definition de awesome para indicar a donde les gustaria llegar.

En cuanto a como tratan impedimentos y como construyen su producto, tambien hay

influencias de Lean Startup. The Lean Startup - Eric Ries.pdf
Agile Coaching
(Addison-Wesley Signature Series) Lyssa Adkins - Coaching Agile Teams_ A Com…
Agile_Coaching.pdf
Ya en su libro XtremeProgramming, Kent Beck mencionaba el término Coach.
roles de XP → Tracker, Customer, Programmer, Manager, Tester y Coach
“Watches everything, sends obscure signals, makes sure the project continues to Stay
Extreme. Helps with anything.”
«Un comunicador, no fácil de asustar, con dotes técnicas y seguridad en sí mismo».

agile coach → entrenador que ayuda a los equipos a crecer fuertes en la aplicación de
prácticas ágiles a su trabajo

«All problems in computer science can be solved by another level of indirection» David
Wheeler

PO y SM → orientados en un único equipo

agile coach → funciona cuando hay muchos equipos → es a nivel organizacional → un

líder, una persona a tiempo completo, con visión global, que alinee a todos los equipos,
resuelva conflictos, ayude a todos a evolucionar.
→ centrado en la comunicación y crear claridad
→ es beneficios que sea externo a la organizacion
 → es por una cantidad limitada de tiempo
→ que todos tengan la misma visión de hacia dónde vamos y por que vamos
→ toma pocas decisiones técnicas y su trabajo es conseguir que los demás
tomen buenas decisiones

SCRUM MASTER AGILE COACH

están a primera línea con un equipo a nivel organizativo

pertenece a un equipo-proyecto específico externo al equipo, no pertenece a un proyecto

normalmente pertenece a la empresa suele ser transitorio y temporal → consultor

externo

táctico estratégico y táctico

sm → tenemos que mejorar las daily → nos da el que

ac → que tenemos que hacer para mejorar? → nos acompaña a descubrir el que

similar a lo que en otras materias conocimos como consultor, pero una versión
evolucionada y centrada en agilidad.
Un agile coach es como un personal trainer.

no queremos lo que podemos leer en un libro sobre agilidad → queremos la experiencia

de alguien aplicándolo → que sea un guia para la transformación ágil en la empresa
debería ser alguien que practico mucho y puede aportar valor desde su experiencia.

cuando su «personal trainer» le decía que ha hecho BIEN un ejercicio… él se lo cree y sabe
que de verdad lo ha hecho bien… porque antes su personal trainer le ha dicho muchas
más veces que “lo ha hecho MAL”.
 COACHING

El coaching se define como un método que consiste en acompañar, instruir y entrenar a

una persona o a un grupo de ellas, con el objetivo de conseguir cumplir metas o
desarrollar habilidades específicas.

coach → “entrenar”, “acompañar”, “motivar”

coach en ámbitos profesionales → proceso de acompañamiento a una persona o a un
grupo de personas en el trabajo con el objetivo de la optimización del potencial de los
individuos → ayudar a ver nuevas perspectivas y posibilidades → ayudar en el
crecimiento en la vida profesional
→ te ayuda a descubrir a nivel personal todas las herramientas que tenes o podes
adquirir para cumplir tus objetivos → es un consultor externo a la organización, pero hay
diferencias con el rol de consultor que conocemos normalmente

Coaching - Coach - Coachee

Coaching → Es la disciplina
Coach → Personal profesional dedicada al coaching
Coachee → Es el cliente del coach

crece el rol del coach por sobre el consultor

consultor → persona que es experta y te ayuda transmitiendo su experiencia → se
centra en el qué y te dice el cómo
Coach → hace que tu obtengas tu propia experiencia, es decir, te ayuda a adquirir tu
experiencia. Mediante la formulación de preguntas te ayuda a ver tu presente y diseñar
tu futuro. → Se centra en el quién para luego pasar al que → te ayuda y acompaña a
descubrir el proceso, el que funcione para vos

→ diferenciación más fuerte entre el ser y el hacer → uno hace lo que hace por como es
je y por experiencias previas
el coach intenta hacer que descubras qué herramientas se tiene desde el “ser” como
persona equipo organización → que puede usar → como maximizar mis habilidades o
prácticas → descubrir que practicas tecnicas aprender → descubrir el proceso

En un proceso de Coaching necesitamos un/a Coach, que acompaña, guía, ayuda a una
persona a la cual denominamos Coachee para que esta llegue a su objetivo (como veremos
más adelante). En este recorrido, intervendrán los siguientes aspectos:
● El/la Coach
● Preguntas y el arte de dialogar del Coach,
● Objetivo del Coachee (su qué),
● Pasos, recursos necesarios y técnicas (sus cómo) para llegar a ese qué
● Los plazos que se van a necesitar (cuando)

En definitiva, es una persona que ayuda a definir un objetivo a otras personas y les motiva
hasta conseguirlo, ofreciendo técnicas para que puedan llegar al objetivo de forma
eficiente y efectiva, también utiliza técnicas de motivación a lo largo de la situación actual
hasta conseguir alcanzar su objetivo.
PRÁCTICAS EN COACHING:

PNL: Programacion Neurolinguistica

Agile Coaching: los niveles de Dilts aplicados a Agilidad

Cómo reprogramar a través del lenguaje ,cambiando la forma de hablar se puede cambiar
la forma de pensar y por tanto de actuar.

Sostiene que de una persona solo se ve el 20% y en el otro 80% no podemos ver:
● sus capacidades
● creencias: es el nivel más profundo en el que podemos generar cambios
● valores: son más difíciles de cambiar, es en lo que se sostienen las creencias
Todo esto oculto se puede ver por medio del comportamiento.

“La confianza es la base de cualquier equipo, debemos generar está confianza para que
tener errores no sean un problema.” Hay que analizar los errores, de cómo se produjo, como
podemos mejorar para que no suceda de nuevo.

- Las quejas en retrospectivas se deben convertir en acciones para solucionarlas.

 - Alianzas: Saca debajo de la mesa reglas misteriosas que el equipo usa pero nunca
se indicaron explícitamente. “Cuanto más explícito -más detalles- es el documento
menor conflictos evitaremos”, si se incorpora un nuevo miembro la alianza se debe
rever.

Conflicto: dos personas quieren conseguir algo pero ambas no pueden conseguirlo porque
es incompatible.

Un agile coach no debería generar conflictos.

Agile Coaching - Piramide DILTS

Pirámide de niveles neurológicos
La utilidad que le damos en agilidad a esta pirámide es para explicar la resistencia al
cambio (cambiar hacia un modelo ágil). Ya que esta muestra varios niveles en los que
trabajar para provocar un cambio. Un cambio en un nivel, normalmente afecta a los
niveles inferiores.

¿Cómo sería entonces aplicar esto al cambio hacia un modelo ágil?

1. Podemos empezar por cambiar a nivel de «Entorno», que sería lo más básico,
quiero, por ejemplo, reducir las interrupciones en el equipo… y nos cambiamos de
sala.
 2. lo anterior puede no ser suficiente sino hay un cambio a nivel de
«Comportamiento», ya que aunque nos cambiemos de sala podemos
interrumpirnos entre nosotros
3. podríamos encontrar que el problema está en el nivel de las «Capacidades», que
lo que necesitamos para controlar la interrupción es formarnos en técnicas de
productividad personal, aprender a usar Pomodoros

Pero, como todos sabemos, muchos cambios no se solucionan con una formación,
porque puede que el cambio sea más profundo.

Si hemos llegado hasta aquí y nada, el cambio está en un nivel superior , en el llamado
nivel de «Valores» o «Creencias». No podemos lograr que les importe ser productivos o
no interrumpirnos, si el equipo no tiene arraigados los valores y principios agiles, o sus
creencias personales van en contra de estos.

cosas que debe saber un agile coach:

● Provocará rechazo
Como agile coach representan el cambio. → cambio ágil → llevar a equipos a entregar
más valor con menos desperdicio, a la máxima velocidad a ritmo sostenible
cambiar cuesta y a muchos no le va a gustar
Eso sí,se debe trabajar con un nivel de rechazo que sea tolerable, porque….
● No todo enfermo es salvable
hay equipos y organizaciones que tienen difícil recuperación, sus probabilidades de
cambio son mínimas y con un desgaste tremendo
● Es mejor que estés fuera y que veas el problema desde fuera
agile coach <> scrum master → el agile coach no está con el equipo que ayuda en su dia
a dia → da la estrategia → pero no esta con el equipo en la ejecución
ventaja: no caer en que equipos te convenzan de que no hace falta cambiar nada
● No cedas en recomendar, tu pones el nivel, ellos el ritmo
agile coach → establece objetivos ágiles → apoya, enseña, mentoriza
equipo → hace “los ejercicios” solo

¿Por qué incorporamos un agile coach?

1. equipo no esta funcionando de manera correcta → no porq no funciona scrum,
porque ahí está el sm → en realidad no funcionamos como equipo agil, no
logramos compartir valores, mantener objetivos → acá interviene un agile coach
2. si tengo un problema a nivel organización → donde no basta un SM que se
enfoca en un equipo específico

Competencias de un agile coach

● Obviamente, tiene conocimientos amplios sobre agilidad, los frameworks de uso
típicos, Scrum, XP, y los que apliquen.
 ● Liderazgo
● Aprendizaje continuo, aquí nadie sabe todo y nunca se deja de aprender, y más
importante aun para alguien que lidera la implantación, y extensión al resto de
equipos, de la agilidad.
● Habilidades, de estas que yo llamo… humanas.

¿Qué hace un agile coach? → nos acompaña en la transformación ágil

Debe tener Conocimientos sobre agilidad y sobre coaching

Mas características de un agile coach:

➔ facilitador → guía → te da las herramientas y técnicas para establecer y
cumplir objetivos → no hace el trabajo por vos → no te da explícitamente
el cómo.
➔ Capaz de dar feedback y saber cómo hacerlo → cuál es el mejor
momento, cuál tipo de feedback → al equipo o a la persona? → para
poder dar feedback → debe ser observador →
➔ Prestar arencion (murió manu agile coach) we loco me mataste →
observar cómo se va comportando el equipo
➔ Nos debe brindar soporte → nos saca el miedos probar cosas nuevas →
proteger al equipo → disponible para el equipo
➔ el agile coach es como un mediador → ante un problema grave → pausar
→ escuchar las partes llevarlo al equipo e intentar que ellos resuelvan →
para que sigan siendo autoorganizados → sino no son equipos ágiles
¿Cómo comenzamos? Método PrOpER

Opciones → herramientas, prácticas, técnicas ágiles

Experimentar → pruebo la práctica,herramienta o técnica elegida dentro de la
organización
Review → en base al experimento (1 sprint por ejemplo) → analizo si nos estamos
acercando a la solución del problema → Si no me acerco, o si podría mejorar → voy con
otra
y se repite también el bucle cuando surja otro problema, que va a surgir.
 UNIDAD 2

MANAGEMENT
PIRÁMIDE DE NECESIDADES DE MASLOW

Dividimos estas necesidades en

necesidades obligatorias → fisiológicas y seguridad
necesidades sociales → el trabajo bien hecho y coordinado en equipo puede ser
mucho más efectivo que el mismo número de individuos trabajando solos en la búsqueda
de cumplir los objetivos organizacionales
necesidades egoístas → estima (reconocimiento, status, respeto de nuestros pares
y superiores) y autorrealización (reconocer el potencial propio, ser creativo, innovar,
autoestima, independencia, cumplir metas, aumentar el conocimiento)
Como organización tiene que ocuparse de satisfacer de manera directa las necesidades
obligatorias y de manera indirecta las sociales o egoístas → Como? Dando un entorno de
trabajo seguro y apto que satisfaga sus necesidades obligatorias, pero como jefe no tengo
manera de asegurar que cada uno cumpla sus necesidades egoístas, pero debo asegurarme
de promover un entorno y una cultura en donde cada uno de los trabajadores sea capaz de
cumplir las necesidades sociales y egoístas
Las necesidades egoístas nunca se cumplen → como humanos siempre queremos MAS →
Las personas siempre desean algo, surgen nuevas necesidades
Una vez que mis necesidades obligatorias están cubiertas, recién comienzo a tener en
cuenta las necesidades sociales . una vez el management garantiza estas necesidades,
cambia el enfoque de la motivación, comienzan a surgir las necesidades egoístas la
necesidad de los trabajadores no solo de tener un buen ambiente de trabajo, pero sino uno
desafiante donde se sientan auto-realizados (o los ayuden a llegar a ese estado)

Una necesidad satisfecha no es un factor motivador

Teoria X y Teoria Y - Modelo de motivación (de McGregor,Cutcher-Gershenfeld)

The Human Side Of Enterprise -Douglas McGregor.pdf

TEORÍA X
Proviene de las ideas del management tradicional o convencional
→ “management by direction and control”
1) El management es responsable de los elementos de la empresa como , dinero,
equipamiento, personas - siempre siguiendo los intereses económicos de la
organización
2) En cuanto a personas, encontrar la manera de controlar sus acciones y
comportamiento para que se ajuste a las necesidades de la organización
Sin la intervención activa de la gerencia, las personas son pasivas, e inclusos resistentes a
cumplir las necesidades de la organizacion → las personas no quieren trabajar -> por lo
que la gerencia debe implementar mecanismos de control y recompensas → debe dirigirlos
→ persuadir, castigar, controlar
Ej: si mi jefe no me dice que me descuentan del salario los días que no voy, no voy nunca a
trabajar

El hombre corriente por naturaleza trabaja lo menos posible, le falta ambición, no le

gusta la responsabilidad y prefiere ser dirigido.
Es por naturaleza resistente al cambio (Ah si? no le conocio a verobollati todavia)

Dentro de esta teoría se concibe que el management puede ser “Duro” (management por
coerción o amenazas, con mucha supervisión para poder controlar) o puede ser más dócil o
“Soft”(permisivo, que todos tengan lo que quieran), siendo ambos dos extremos. Y en el
punto medio “firm but fair”.
firm but fair → “Speak softly and carry a big stick” -Roosevelt → estas ideas siguen en el
management basado en control, por lo que los métodos de este management fallan al
querer motivar personas que ya tienen satisfechas sus necesidades básicas (safety needs)
y predominan sus necesidades sociales, egoístas y de autorrealización
El management by control no es compatible con la motivación

TEORÍA Y
La gente no es por naturaleza pasiva, pero pueden serlo por experiencias pasadas en su
trabajo
La gerencia es responsable de organizar las necesidades económicas, materiales,etc n →
necesidades básicas
La motivación, el potencial de crecer, la responsabilidad y disciplina, dirigir nuestras
acciones y comportamiento hacia el cumplimiento de objetivos organizacionales: son todas
características que los trabajadores pueden tener si el management los ayuda a
reconocerlas y desarrollarlas. La tarea esencial de la dirección es organizar las condiciones
y métodos (un entorno) para que la gente pueda lograr sus propios objetivos de motivacion
sociales o egoístas → crear oportunidades, remover impedimentos, incentivar el
crecimiento profesional (de manera personal y dentro de la organziacion), guiar.

Se utilizan practicas como la descentralizacion en las organizaciones y delegar la toma de

decisiones → “un cierto nivel de libertad en las actividades, asumir responsabilidades mas
grandes y satisfacer necesidades relacionadas al ego”
Otro ejemplo es el Job Enlargement de IBM

“management by objectives” > “management by control”

Management 1.0
→ Derivado de la era industrial →
Basado Taylorismo→ división de las distintas tareas del proceso de producción → método
de organización industrial → aumentar la productividad → evitar el control que el obrero
podía tener en los tiempos de producción.
→ las personas no son importantes , son un recurso más

Management 2.0
→ Propuesto Peter Drucker (Padre del Management moderno)
Diferencia a los “trabajadores del conocimiento” → es evidente que no es lo mismo trabajar
en una fábrica que en la construcción de un producto de carácter intelectual
Propone que las personas son importantes pero se siguen manteniendo
estructuras burocráticas donde las decisiones son tomadas por un pequeño grupo de
personas
 Las personas pueden marcar la diferencia entre el éxito y el fracaso de un proyecto

PEOPLEWARE
PeopleWare: Productive Projects and Teams -DeMarco.pdf
Básicamente, Peopleware → las personas son importantes

Management 3.0
Addison.Wesley.Management.3.0.Jan.2011.ISBN.0321712471.pdf - Capitulo 5 y 6 (pag 93 delpdf)
Dentro del marco del Peopleware tenemos las prácticas de Management 3.0 propuesta por
Jurgen Appelo.

un equipo de desarrollo, lo podemos ver como un sistema que consume y produce

innovación → teniendo a las personas como su parte más importante
por lo que el management 3.0 se enfoca en → Energizar a las personas → definiendo 5
criterios necesarios para que este sistema de personas funcione

Conocimiento, Creatividad, Motivación, Diversidad y Personalidad

al ser un trabajo intelectual se debe incentivar la creatividad, para tener innovacion, y así
garantizar que la organización sobreviva → para esto el management debe crear un entorno
propenso a la creatividad
→ información y conocimiento disponible y un conjunto de personas motivadas con
un mix de personalidades
→ también aspectos de su entorno → seguridad, “play”, visibilidad, variar, “edge”

equipos → responsables del trabajo que hacen, los proyectos en los que trabajan
managers → responsables del entorno en que trabaja el equipo

MOTIVACIÓN INTERNA Vs MOTIVACIÓN EXTERNA

Motivación externa “Extrinsic motivation is defined as behavior that is driven by

external rewards,by others, money grades praise”

→ basado en Teoría X → nos la dan los jefes, gerentes → beneficios monetarios (aumentos
por mérito, incentivos, bonus) y “halagos y cumplidos”
puede provocar roces entre empleados o competencia innecesaria entre ellos, destruir la
motivación intrínseca y una “adicción” de motivación extrínseca (ej: cumplo por mi trabajo
solo por querer impresionar a mi jefe, tratando de hacer todo de la manera que se que al jefe
le gustara, dejando de lado mis conocimientos, criterio y creatividad)

De igual manera, esto no significa que no haya ni un componente de la teoría X que no

funcione. Dar bonos o extras no es necesariamente malo, pero debemos hacerlo de una
manera que no tenga estos malos efectos secundarios. → En sistemas complejos los
efectos malos de la motivación externa son impredecibles y suelen opacar los beneficios
La motivación externa puede inhibir la creatividad, o por lo menos no propiciarla

Motivación interna →“Intrinsic motivation is defined as behavior that is triggered

from within a person. In other words, the person is rewarding herself.”

las personas tienen naturalmente el deseo de que les vaya bien y cumplir sus objetivos
la creatividad está basada en la motivación intrínseca
(creatividad = link entre conocimiento → información)
querer hacer una actividad porque realmente deseo realizarla y terminarla, no por
obtener alguna recompensa externa

managers → objetivo = que la organización sobreviva → focus on innovation → focus en

creatividad para tener innovación → motivación intrínseca para tener creatividad
Nuestro trabajo es nuestra recompensa → no es quiero el resultado B asi que doy un
incentivo A → A = B

la motivación intrínseca es la más fuerte de las motivaciones

La motivación externa no nos garantiza que se cumplan las tareas → la interna si
La motivación externa puede tener efectos negativos
motivadores del tipo «logra esto y te recompenso (o castigo) con esto otro» no funcionan
para todo tipo de tareas e, incluso, pueden perjudicar. Incentivos , económicos por ejemplo,
pueden llegar a servir en tareas simples pero no en sistemas complejos
¿Qué te motiva mejor para este tipo de tareas? Construir motivadores en base a la
motivación intrínseca, generar el deseo de lograr cosas porque nos importan.

FACTORES DE MOTIVACIÓN

No podemos motivar a alguien solo evitando desmotivarlo

La satisfacción y disconformidad con algo son independientes entre sí → las cosas que
nos motivan son diferentes de las que nos desmotivan → no por eliminar lo que
nos desmotiva, garantizamos motivación
ej: soy manager y gestione que tengamos un espacio de trabajo adecuado, bien
organizado y cómodo, con equipamiento de calidad. pero en realidad mi equipo no se
lleva bien. por lo que garantice un aspecto que los desmotiva, sin enfocarme en lo que
si los motiva, por lo que de igual manera mi equipo no le gusta trabajar juntos.

Acá entra lo que mencionamos de satisfacer de manera directa necesidades

obligatorias y de manera indirecta necesidades egoístas. Por eso el uso de nombre
“higiene” u “obligatorias”, esos factores no hacen felices a las personas, pero la
ausencia de ellos puede deteriorar su salud y felicidad, y por ende su motivacion.
También se propone construir esos motivadores en base a la autonomía, maestría (ser
cada vez mejor) y propósito (lograr algo que importa).
En general se dice que la motivación de los trabajadores del conocimiento se basa en
estos factores:
Conocimiento → Personas a las que les gusta transmitir lo que saben (yo) y que les
gusta aprender. El aprender motiva a la gente y la gente con conocimiento atrae.
Libertad → libertad en nuestras acciones → por ej poder decidir horarios, tener zonas
de relax, o zonas de juego, esto no podemos hacer si no tenemos responsabilidad →
poder tomar nuestras propias decisiones
Honra → hay gente que necesita tener personas a quien respetar , crea lealtad, Las
acciones honorables motivan y generan una gran confianza.
Poder-estatus → Cargos, títulos, elevar su condición social, títulos, premios,
certificaciones, referencias, acreditaciones, etc. Una manera de motivar en este sentido
es usar símbolos que representan el status, como hace la “gamificación”, el otorgar
premios públicamente, por redes sociales, en privado, etc.
Relaciones → El establecer relaciones motiva, abrirnos como personas, darnos a
conocer, conocer la vida personal más allá de la profesional ayuda o incentiva a que los
demás también se den a conocer, estableciendo una relación más cercana y confianza
Orden → generalmente la gente que le motiva el orden necesita tener un objetivo bien
definido
objetivo → Tener un gran objetivo, luchar por una causa, un objetivo noble… motiva. →
“Misión es lo que quieres para ti, y una visión es lo que quieres para los demás”
¿Por qué tengo que conocer qué motiva a las personas dentro de mi equipo? asi puedo
planificar acciones que los ayude a estar motivados

HAPPY WORKERS DO MORE AND ACHIEVE MORE

 relación motivación-compromiso-felicidad

¿QUE HACE FELICES A LAS PERSONAS EN UN TRABAJO?

Para asegurar que las personas en la empresa sean felices se
debe primero averiguar qué motiva a cada uno y buscar formas de
poder ayudar y guiar al equipo en ese camino de felicidad.

Para lo que Jurgen Appelo formula su

12 STEPS TO HAPPINESS
#Workout -Jurgen Appelo

1. THANKS
Agradecimiento entre pares → motiva mucho mas a que venga de un jefe
Hay herramientas que ya tienen incluido features para dar recompensas o felicitaciones
(slack, linkedin, trello)

2. KUDOS
Dar un reconocimiento material a alguien → se realiza una ceremonia

Esto no cuenta como motivador externo, aunque sea algo material o monetario, porque
viene de los pares, no del jefe.
3. HELP
4. EAT WELL

5. EXERCISE

6. REST

7. EXPERIENCE

8. MEDITATE

9. SOCIALIZE
 10. AIM

11. SMILE

Otras Prácticas Propuestas por el Management 3.0

Un resumen de las características más relevantes de una persona; sobre su personalidad,

gustos, día a día, aspiraciones, valores, su historia, etc..
Hay dos maneras de hacer esta práctica:
1. Hago mi propio mapa y en una reunión me presento (las presentaciones que
hacemos en esta materia)
2. De a pares → dos personas nos ponemos a hablar para que cada uno haga el mapa
del otro → nos hacemos preguntas, nos interesamos por la vida personal de los
 compañeros, creamos vínculos → una vez que tenemos los mapas nos presentamos
entre sí

Speed Dating
Cada persona integrante del equipo tiene un listado de
preguntas (que se arma en equipo) y van referido a lo
personal.
Se hacen dos filas, y una persona pregunta a la otra y así se
van tomando turnos.
Está técnica es buena cuando es un equipo grande e inicial.
Lo malo de está técnica al final es una técnica más dirigida,
no nos enteramos todos.
Bueno para cuando el equipo es incial

NikoNiko Calendar
Niko = Sonreir \ Niko Niko = estado de ánimo
Se implementan calendarios, mensuales o semanales, al salir del trabajo cada uno indica
cómo les fue, cómo se sienten, ese día, cómo están ellos con respecto a su trabajo hoy .
Para esto usan emojis o códigos de colores.
Esta práctica es para el equipo, sólo ellos deberían ver los resultados.

→ Tuve un dia productivo

→ No tuve ni un buen ni un mal dia
→ Tuve problemas

Luego de ese periodo definido se debe analizar como estuvo la jornada y ver en que
podemos mejorar como equipo. También si notamos que alguien esta teniendo problemas,
preocuparnos por el compañero, ver que hace que no sea productivo, nuestras vidas
personales también influyen.
Para que la practica funcione debe estar garantizada la personal safety, debo tener la
confianza de poder expresar lo que siento.

Happiness Door
Reconocer algo que:

Me pareció interesante
No me impactó tanto
No me gusto

Se pone en un lugar visible por todos. A pesar de ser anónima tiene que haber
seguridad psicológica. Hay que analizar lo que dicen y tomar acciones, sino la gente
deja de aportar.
Estas actividades nos sirven para la inspección, encontrar aspectos de mejora, pero si
ponemos estas herramientas en la organización luego hay que tomar acciones en
base a lo encontrado.

TShirt Test
¿Te pondrías una camiseta de tu equipo/empresa fuera del trabajo?
Mide el grado de compromiso o engagement. Cuando una persona está comprometida, está
orgullosa de la empresa en la que trabaja (
MERIT MONEY
Jurgen Appelo - Merit Money.pdf
Como managers, una de las tareas más difíciles es decidir cómo le pagamos a las personas
por su trabajo, sin destruir su motivación. Por lo que el management 3.0 propone algunas
prácticas, como el merit money, donde las ganancias puedan estar basadas en mérito real.

¿Qué pasa cuando hay un poco de dinero extra en la empresa en algún momento? (un
producto que le fue muy bien, una campaña que dio buenos resultados, cerrar con un cliente
importante). Qué hacemos con este dinero? Aumentar el salario de todos probablemente no
sea sustentable en el tiempo. Otra “buena” idea podría ser mejorar la oficina, renovar
equipamiento, pero esto normalmente sólo favorece a algunos trabajadores más que otros
(y como nos aseguramos de que estos se lo “merecen”¿?).

A una persona deberían darle lo que realmente se gana, y estas ganancias son resultado de
las interacciones de la organización con su ambiente

En un intento de lograr esto, surge el “Sistema de Bonos” tradicional que conocemos,

anual o semestral. Los managers dan “objetivos”, y a partir de ellos calculan su bono
teniendo en cuenta su performance, puesto de trabajo, salario, antigüedad, edad, y un
montón de variables que poco reflejan su verdadero mérito.

Tener únicamente motivadores extrínsecos, como bonos previsibles y de caracter

monetario, mata la motivación real de las personas. Trabajan por el bono, no por el
trabajo en sí, y además seguro que cuando llegue no les parecerá suficiente (empezó
diciembre y ya revente la tarjeta, llega el aguinaldo y al final no me alcanza para pagar
mi resumen…). Comienzo a verlo más como un derecho , y no algo que me tengo que
ganar.
sobre todo esto no es beneficioso en “trabajadores del conocimiento”, un bono
normalmente no ayuda a mejorar su performance si hace trabajo creativo e intelectual.
 TODO LO QUE ESTÁ MAL CON EL SISTEMA DE BONOS:
1. Las personas se vuelven adictas a recompensas regulares, y sino se sienten
decepcionados, castigados y desmotivados (por lo que baja su performance)
2. Recompensas individuales pueden afectar a la colaboración, y este es un aspecto
muy importante del conocimiento creativo. Incentiva la competencia, y la trampa en
ella. Arruinando relaciones entre compañeros o entre managers y trabajadores.
3. Los bonos tradicionales se basan en métricas “objetivas” (tareas completadas,
horas extras trabajadas, ganancias directas). Pero estas ignoran características
importantes como el trabajo en equipo, la colaboración, y el comportamiento en sí
4. Estar pendientes de la fecha del bono y como hacer para cobrar mas, distrae a la
gente de realizar tareas complejas y ser creativos. Son precavidos y no toman
riesgos para no afectar sus ganancias. Pero si queremos innovar, necesitamos un
ambiente “seguro para fallar”
5. “Si me pagan extra por hacer esto, el trabajo no debe estar bueno ni ser
interesante”, destruimos la motivación intrínseca

A partir de esto surgen propuestas como tener un sistema “Flat”, todos ganamos lo mismo,
no hay bonos. Partiendo de la idea de que “el éxito en la compañía lo da el sistema que
implemente, no las personas”. Sabemos que eso no es cierto.
Claramente esto puede generar roces entre las personas. “Por que gano lo mismo que
alguien que no hizo ni la mitad de todo lo que yo trabaje?!”, se dice que al menos el 80% de
las personas piensa que su performance es mejor que los demás

Normalmente en una empresa cuando a esta le va mal, lo sufre toda la empresa (hay
despidos, recortes de presupuestos, etc) pero cuando le va bien pareciera que solo la
organización se beneficia, o solo los niveles mas altos (le damos un bono al jefe porque su
equipo fue el que mayor ganancias trajo a la empresa, ..pero y el equipo?)

JURGEN APPELO EN EL DESAFÍO DE DEFINIR UN SISTEMA DE

RECOMPENSAS BASADO EN MÉRITO REAL FORMULA MERIT MONEY

Todos deberían tener un salario fijo y razonable (garantizar necesidades

básicas u obligatorias). Pero, sobre todo al trabajar en organizaciones
ágiles donde el ambiente es impredecible y cambiante, los trabajadores
deberían llevarse extras de acuerdo a estos cambios en este ambiente
incierto. La cantidad de los mismos debe ser justa y basada en mérito
real
1. Los salarios deberían ser esperados, los bonos no
Si se vuelven regulares y anticipados,se convierten en un salario más
2. Las ganancias deben ser basadas en colaboración, no en
competencia
Contribuciones a los objetivos comunes del equipo, o de toda la organización
3. El feedback entre pares es la mejor medida de performance
Solo el sistema por dentro sabe como funciona realmente, no es lo mismo que tu jefe te
diga que hiciste un buen trabajo basado en tus resultados, a que lo haga un compañero
basándose en tu comportamiento
4. Usar el pensamiento creativo para hacer que el sistema de compensación
crezca
Como manager, o como quien propone el sistema, tienes que aceptar que si trabajas en un
entorno creativo basado en la colaboración, las personas van a hacer...bueno eso. ser
creativos, “jugar con el sistema”, cambiarlo, adaptarlo. como manager hay que incentivar
esto, no quedarnos en que “No cambien nuestra idea”.
5. Usar estas compensaciones para incentivar la motivación intrínseca
Que el dinero sea un reflejo del comportamiento de las personas, recompensar por factores
“intrínsecos” también, la curiosidad, honra, conocimiento, colaboración, etc

Para esto es indispensable tener un entorno safe-to-fail.

Crear una virtual currency, algo que no tenga un valor monetario asociado
directamente (puntos, fichas, caramelos, stickers, emojis, abrazitos, sombreritos), no
tienen valor hasta que el management decida asociarse uno, de manera no previsible.
Este reconocimiento debe ser entre pares.

Luego debemos decidir qué unidades dentro de la organización estarán dentro de este
sistema, y quien le puede dar sombreritos a quien (solo dentro del equipo? ¿Puedo
dárselo a un individuo de otra unidad? puedo dárselo a todo un equipo que no es el mio
porque nos ayudaron?). En organizaciones donde los equipos se manejan “con
representantes”, no resulta muy beneficioso dar rewards entre equipos, a quien se lo
damos al manager y él decide? como se quien del equipo se lo merecía en realidad?
De lo que podemos identificar dos tipos de equipos, para los que contemplamos dos
tipos de reconocimientos distintos:
→ varios equipos que trabajan para un mismo cliente o proyecto particular
→ Equipos que no comparten el mismo cliente, pero si herramientas, prácticas o
tecnologías
Debe haber una cantidad limitada de bonificaciones, por ejemplo arrancamos cada mes con
20 sombreritos y lo repartimos como queramos y cada mes se reinician nuestros
sombreritos disponibles. Es importante remarcar, que estos sombreritos solo tienen valor
alguno cuando nos lo da alguien más, el mérito debe ser ganado, y las opiniones de todos
son igual de importantes.

La idea es que se crea un mercado de mérito, y como todo mercado, debemos esperar que
la personas quieran jugar con él, experimenten, sean creativos. Cada uno puede entregar sus
sombreritos basándose en el criterio que le parezca, podemos dar nuestra propia definición
de que es una buena perfomance o alguien colaborativo. Pero si es importante promover la
idea de tener en cuenta un objetivo en común, que estarán alineados a los objetivos de la
empresa.

El management puede apartar mensualmente por ejemplo, una cantidad para bonus, pero
estos no deben ser previsibles. Generar alguna práctica en la que de manera random se
decida si ese mes se da o no el bono, por ejemplo tirar un dado y solo si cae 6 hay bono,
sino veremos en el próximo periodo
El valor de cada sombrerito depende de la cantidad de sombreritos entregados y del dinero
disponible en la empresa, por lo que dejamos claro que si a la empresa le va bien, al equipo
también.
la performance del equipo va bien y son colaborativos → a la empresa le va bien → el
equipo tendrá mayores ganancias

Además cuando los sombreritos se vuelven canjeables, la persona puede elegir hacerlo o
guardarlo, esperando que futuro valga más o le sirva más (capaz esto no funciona en
nuestra inflación:/, pero si estas re confiado que a tu equipo le va a ir mejor el próximo mes
metele)
LAS 6 REGLAS DE LAS RECOMPENSAS:
1. No prometer recompensas por adelantado
2. Mantener pequeñas las recompensas anticipadas
3. Recompensar continuamente, no una sola vez
4. Dar recompensas de manera pública, no privada
5. Recompensa comportamiento, actitudes, no resultados
6. Recompensar entre pares, no a subordinados.

Entornos de Productividad
Siempre estamos buscando mejorar la productividad → si aumenta la productividad
pueden aumentan las ganancias, si cae la productividad siempre termina impactando
en los costes
Lo más importante son las personas → personas motivadas son + productivas

Entrega de valor con tiempo en calidad y con felicidad

Las personas que son felices son 12% más productivas

“La función de un gerente NO ES hacer que la gente trabaje, es hacer todo lo posible para
que la gente PUEDA TRABAJAR” -DeMarco

Garantizar el entorno necesario para que las personas puedan trabajar

Pero no solo la motivación infiere en la productividad, hay otras circunstancias que

hacen que la productividad disminuya.
→ entorno físico
por ej en teletrabajo:
● armar rutina de trabajo → levantarse vestirse
● tener espacio de trabajo <> espacio de descanso

¿Hasta qué punto el entorno físico influye en la obtención de resultados?

¿Malas condiciones físicas? ¿Luz natural? ¿Mala ventilación? ¿Sistemas de fichar?

Todo esto impacta en cualquier tipo de equipo de trabajo, pero sobre todos en los
trabajadores del conocimiento
Sistemas de fichar → tiene un impacto muy negativo en la productividad. Porque a
veces soy creativo en horarios que no tengo que ser creativo → una mejor idea es
permitir elegir horarios de trabajo.
→ puedo marcar mis 8 horas y estar sentada mirando tiktoks (donde mando cv
para eso?) → controlar que cumplan un horario de trabajo no me asegura que voy a
tener un trabajador productivo → si tengo un horario de salida fijo, 30-20 mins antes
estoy esperando a irme y no soy productiva

Puedo decirle a un obrero que sea productivo a las 7am, pero puedo decírselo a un
ingeniero?

profeVero: Esta supercomprobado que con horarios fijos no somos productivos

Técnicas de manejo del tiempo

1. Crunch Mode → trabajar +40hs x semana → cuanto + trabajamos + productivos

...mm seguro?
→ no es sostenible → la gente se cansa, se estresa, no termina rindiendo → esta
super comprobado que tampoco se cumple
Las horas extras son productivas cuando son esporádicas. Cuando las horas extra es
lo común → deja de ser productivo

2. Ritmo sostenible → en contraposición al crunch mode →

Encontrar una cantidad de tiempo menor a 40 horas semanales en las cuales el
equipo sea productivo y mantener el ritmo de trabajo en el tiempo → elegir trabajo
que podamos hacer en ese tiempo → pero sin un horario fijo obligatorio
Trabajar más horas no significa más productividad → llega un punto en que cuanto
más tiempo estamos trabajando esas horas extra hace que el equipo sea mas
destructivo que productivo, más errores, etc.
Un equipo sobresaturado no se traduce en mayor efectividad y beneficios
 3. Slack → Propuesta por Mac DeMarco (autor peopleware) → definir slacks en los
que el equipo es productivo → periodos de tiempo que el equipo va a a trabajar
slack significa distensión → implementar esto habla de darle libertad a la gente para
que sean mas productivos e innovativos → definir tiempos donde el equipo no es
productivo
que un equipo esté muy ocupado y sobresaturado… no se traduce en mayor
efectividad y beneficios, es imposible que una persona pueda invertir todo el tiempo
de su horario de trabajo en hacer cosas productivas.

LAS 6 RAZONES POR LAS QUE CRUNCH MODE NO FUNCIONA

Rule #1
La productividad varía durante el día de trabajo, con los mayores picos en las primeras 4 a 6
horas. Luego de una cantidad suficiente de horas, la productividad se acerca a 0, y si
seguimos eventualmente se vuelve negativa.
(negativo → cansancio que se acumula y luego al otro dia tampoco quiero trabajar)
Rule #2
Es difícil determinar horas productivas de un trabajador del conocimiento
→ práctica heredada de industrias viejas → la versión en IT de ets mala práctica, es
medir productividad con cantidad de lineas de código, o commits si lo hacemos más
moderno
Rule #3
trabajar 5 días a la semana de 8 horas maximiza los resultados a largo plazo, por que
pensamos que nuestra industria está exenta de esta regla?
Muchas de las cosas que en otras industrias funcionan, en la del software, o en la del trabajo
intelectual en si, no funcionan.
Rule #4
Si establecemos 60 hs semanas, la perdida de productividad causada por trabajae tantas
horas sobrepasa a la cantidad de trabajo realizada en esas horas “extras” antes.
La pérdida de productividad se va a notar cuando lo mantengo en el tiempo → porque impacta
en el cansancio
Rule #5
El trabajo en exceso de manera continua reduce las funciones cognitivas en un 25% por
cada 24hs. Múltiples “trasnochadas” de trabajo o estudio tienen muy malos efectos, y son
acumulativos.
Al reducir la función cognitiva, que me deja tener los procesos creativos, lo que impacta
también es en la cantidad de errores que voy atener, por estar cansada, saturada, sin dormir.
Rule #6
La tasa de errores cometidos aumenta cada hora de más trabajada con falta de sueño o
estrés por estar sobrepasados de esfuerzo. Eventualmente, a todos nos pasa, y pueden
ocurrir catástrofes. si las fechas están ajustadas y el riesgo económico es alto, por que
hacer esto?
Si te explota el error en la cara →es porque ya esta en producción → ahora afecta al
mantenimiento → y normalmente no soluciona el error el mismo que hizo el producto

Ya sabemos que no se puede medir tan fácilmente la productividad de un

trabajador del conocimiento. Pero entonces en que nos basamos? En la velocidad
del equipo, y en valor entregado, working SW

No solo debemos pensar en manera de ser mas productivos, sino tambien en reducir, y si
es posible, eliminar todo desperdicio que frene nuestra productividad

Desperdicios que Frenan la Productividad

#1 TAMAÑO DE LOS EQUIPOS
Sabemos que los equipos agiles deberían ser pequeños (7+-2 personas). Si son menos de
3 personas ya perdemos los beneficios del trabajo en equipo, algunas practicas no se
pueden hacer o no tienen sentido. Si somos +9 personas, caos, mala comunicacion; ademas
empieza a ser improductivo (muchas manos en un plato hacen mucho garabato)
A mayor cantidad de gente → aumentan los canales de comunicación
Además ya estamos familiarizados con el gran error de añadir gente nueva a un proyecto
atrasado.
Una persona nueva a un equipo tarda maso 3 meses en llegar al nivel en el cual está el resto
del equipo → Gente de mi equipo tiene que explicarle cómo hacer las cosas
→ Si ya no cumplo los tiempos, el presupuesto debe estar ajustado, contrató gente no tan
capacitada → Jrs → hay que usar tiempo en capacitarlo

Entonces, ¿cómo funcionaban” las metodologías clásicas donde había equipos grandes?
porque no era el equipo el que tomaba las decisiones, habia un jefe que decidía por todos,
por lo que no podía haber problemas de comunicación entre el equipo.
#2 INTERRUPCIONES
Las interrupciones afectan mucho nuestra productividad, aunque no solo por la
interrupción en sí, sino por lo que nos toma volver a concentrarnos después de que nos
interrumpen (aprox 10-15 min)
 //”te puedo interrumpir un ratito?” ya es interrumpir

Además podríamos pensar que normalmente las interrupciones no son urgentes, pero ahí entra
en juego que consideramos urgente, lo urgente para un compañero puede que no sea tan
relevante para mi.
Como todo, el equipo debe definir su concepción de urgente en su alianza (así como tenemos un
DOD podemos tener un DOU definition of urgent).
Como equipo damos lineamientos de “Cuando interrumpirnos”, y todos deben estar al tanto→
hay que negociar de antemano cómo vamos a trabajar

#2.1 ESPACIOS ABIERTOS

ventaja → mejora la comunicación osmótica y el compañerismo
desventaja → interrupciones → ej: estoy concentrada en algo, pero mi
compañero esta descansando y se va a hablar a alguien en la mesa de al lado, y rompe
mi concentración
 Solucion → habilitar espacios separados
no siempre es posible tener todo, pero intento ser buena compañera, para reunirme
con la gente voy a un lugar separado de donde estoy trabajando → No interrumpir al resto
→ej: si no hay espacio vamos a la cocina
Tener espacios organizados, sectorizados por equipo o por lo menos un pco mas
alejado del resto → ej: organizar una mesa por
equipo
Otro gran error es no tener momentos de relax y espacios de ocio, para no saturarnos y
desgastar nuestra productividad
#2.2 USO DE REDES SOCIALES
No solo nos referimos a limitar su uso, sino también definir como equipo la manera en que
las usamos para comunicarnos y no interrumpirnos entre nosotros. Definir horarios, y que
fuera de estos las notificaciones de deshabilitan automáticamente

Luego esta el consumo personal de las redes, que nos distraen mucho, lo ideal es cerrarlas
mientras trabajamos. A todos nos paso estar estudiando muy concentrados, suena el
teléfono, y para cuando me di cuenta ya estoy en tiktok; o me pongo un pomodoro en
youtube me distraigo un ratito y estoy viendo videos de 1hora de alguien derritiendo metal.

Tiempo de resolución = T (tiempo que me lleva hacer la tarea) + 15mins (volver a

concentrarme) + duracion de la interrupción
#5 REUNIONES INTERMINABLES
reuniones largas, improductivas → no solo pierdo el tiempo de la reunión → Me hace
entrar en un estado de enfado desde que me convocan a la reunión, siento que estoy
perdiendo tiempo

soluciones →
TIME BOXING → Establecer antes de la reunión cuánto durará, qué temas se
abordan, y tener un facilitador que guía la reunión
facilitador → obligación de cortar si nos desviamos del tema → o también si nos
extendemos más de lo necesario en el tiempo , si esta siendo redundante, si “se va por
las ramas” → que el facilitador tire un bueno...seguimos…
 #6 MULTITASKING
EL MULTITASKING NO FUNCIONA (por mas que yo me quiera convencer que si :( )
No solo por el hecho de poder o no hacer varias cosas a la vez, sino por el tiempo que
toma el cambio de contexto de una actividad a la otra.
-> Si trabajo en 5 proyectos a la vez tardo más adaptandome cada vez que cambio de un
contexto a otro que trabajando en los proyectos en sí

Limitar el número máximo de tareas que se pueda realizar → KANBAN WIP LIMIT →
tableros kanban nos establecen una cantidad max de HU en la columna doing

Extra: Método verobollati contra la procrastinación

Mas que una rutina → entrenamos la concentración y organización → hay que
crear habitos no rutinas
1. Elegir una herramienta → tablero, cuaderno, pizarr, jira, trello , etc
2. Hacer una lista → lista consciente de todo lo que tenemos que hacer
3. Priorizar las tareas = priorizar mi backlog
¿Cuáles son las cosas que tengo que hacer si o si? ¿Qué tengo que hacer primero?
tengo que cumplir con deadlines?
4. DOD
Definir cuando una tarea está terminada
Si comienzo una tarea la termino → listado de aspectos que significan que está
terminada
ej: estudiar unidad x → que esté terminada significa: leer todas las filminas, resumir, hacer
ejercicios
5. Asignar tiempo
definir tiempos para cada actividad
pomodoros → intervalos fijos de tiempo en los que trabajó → Durante un pomodoro no
hago otra tarea a parte de la que estoy haciendo, no intercalar entre varias → hacer una
tarea hasta terminarla

pensar en las tareas que tenemos que hacer como un backlog

→ necesita priorizarse
→ es cambiante
TÉCNICAS QUE AYUDAN A MEJORAR NUESTRA PRODUCTIVIDAD

→ Pomodoros
→ciclos de (25 min trabajo - 5 min descanso) x 4 → luego de los cuatro ciclos nos
tomamos un break mas largo 15-30 min → podemos personalizar los intervalos, pero
debe ser constante
Construir de a poco el hábito → luego es una medida de nuestra productividad → puedo
determinar mejor cuanto me toma hacer alguna tarea
→ tachar tareas, completar ciclos, mandar a columna del done → nos da la sensación
de que efectivamente fuimos productivos, nos mantenemos motivados, mejora la
organización

→ EL IMPACTO DE LA NO-CALIDAD
No hablamos de la calidad que vimos en ing de sw

Calidad técnica → Cada persona del equipo debe ser responsable y consciente del
impacto de la no calidad
Todos deben conocer las buenas prácticas → prestar atención a métricas como la
complejidad ciclomatica --> tener en cuenta su efecto en la calidad tecnica

Todo lo que haga mal hoy, alguien va a terminar pagando → no lo arregla quien
desarrolló el error normalmente → paga el que mantiene el código
Todo lo que dejamos “atado con alambre” → después hay que mantenerlo
Cuando cae la productividad se disparan los costes o bien atraso el proyecto, o añado
gente (lo peor que puedo hacer en un proyecto atrasado es contratar más gente)

En SW no puedo elegir no pagar por la calidad → lo que ahora llamamos deuda técnica
Tenemos deuda técnica buena y mala → la deuda técnica mala es la que impacta en la
productividad
No hay que esperar que los jefes o el equipo nos diga lo que tenemos que aprender →
Es nuestra responsabilidad

EQUIPOS

MULTIFUNCIONALIDAD
Tener un equipo multifuncional no significa que todos saben hacer todo, sino que
dentro del equipo se deben tener todas las capacidades necesarias para desarrollar el
proyecto → tener expertos pero tmb gente los sepa suplantar o aprender si se lo
necesita

Queremos evitar tener 1 solo experto en cada tema → “solo el puede tocar la bdd” → y si
el no esta, que hacemos? no podemos seguir trabajando?

El problema de los silos

cascada → etapas → tenemos especialistas → no hay comunicación entre los distintas
de áreas de especialidad
mucha burocracia para comunicarme con cada área → se generan cuellos de botella
“nadie más que los de diseño saben de diseño”

equipos agiles → cada integrante tenga lo que se conocen como habilidades en T

Se necesitan conocimientos en otra área → no hace falta ser experto →

si el experto falta → hay alguien que puede hacerlo → no lo voya hacer con demasiada
calidad técnica, pero el proyecto no se va a paralizar

MATRIZ DE CARACTERÍSTICAS/NECESIDADES

Estrella → experto
Puntito → sabe algo, esta dispuesto a aprender
Columna vacía → no se nada y no me importa

Sirve para saber si mi equipo es multifuncional

También me muestra en qué áreas debo reforzar
Es una herramienta → por lo que es adaptable → lo ajusto a mi equipo
tampoco es fija → debería ir actualizando → porque tenga un un puntito no significa que
me quedo asi siempre → intento aprender y ganar mi estrellita :)
no buscamos que todos sean expertos → pero siempre estar cubiertos
Se busca que el equipo sea estable → está trabajando hace muchísimo tiempo juntos →
la multifuncionalidad del equipos e incrementa
Mientras más tiempo hayan trabajado juntos aumenta la productividad y sinergia del
equipo
Calidad del equipo → equipo estable
equipo estable → saben lo que hacen y cómo hacerlo → se pueden adaptar a muchos
proyectos distintos dándole la impronta del equipo

No significa que nadie puede cambiar, o no pueden quitar o agregar gente → pero lo
hacen de una manera tal que se mantenga la cultura del equipo estable
Si ya está establecida la dinámica del equipo → este puede variar, pero siempre
manteniendo su esencia

¿Cómo de estable es el equipo? ¿Cómo están trabajando juntos? que calidad tiene el
equipo?
→ Team Barometer
→ orientado a soft skills → también puede tener
aspectos técnico
Se ponen post-its en cada columna, no hace falta que se
complementen todos → evaluar lo que es relevante para el equipo
Dar evidencias → No me digas que en colaboración o
confianza estamos bien , dame un ejemplo, una situación concreta
que evidencie que tenemos o no ese aspecto → Para esto debe haber confianza
ver cuando usamos esta herramienta → no hago una retro si tuvimos un mal dia →
vamos a estar ~sensibles → no dar feedback después del hecho que desencadena la
necesidad de dar feedback → dejar pasar 2-3 días: si pasa mas ya me olvide los
detalles a decir(manu no se va a acordar ni que paso algo por ej) → más tarde no tiene
sentido no puedo tomar análisis

siempre enfocarse en el hecho no en las personas

RETROS:
temporales → por ej a fin de cada sprint
por hechos → paso algo de lo que debemos hablar

vbollati tip → nunca tomarlo personal → dejar de lado el ego

1) Rule #1 → el feedback no se contesta
2) ¿Me sirve lo que me está diciendo?
3) ¿Cuáles son las acciones que hacen que esta persona sienta eso?

→ MODELO TUCKMAN
Es un modelo antiguo (1965), pero lo podemos adaptar a la agilidad. Nos sirve para recordar
que los equipos no comienzan totalmente formados, y la importancia de construir la
madurez del equipo. Primero son solo un grupo de personas juntas para lograr algo. El
equipo debe ser estable y necesita tiempo para lograr esto, para lo que deben pasar
distintas etapas para convertirse en un equipo, necesitan tiempo para crecer y ser
productivos.
Gente junta no necesariamente es un equipo
 1) Etapa de formación → conocernos → hay que darle un tiempo a esto para
que el equipo pueda llegar a ser estable, pero no demasiado → todo el
mundo se preocupa, principalmente, por buscar cuál es su lugar en el
equipo.
2) Storming/confrontación → se empieza a discutir cual es la mejor manera
de hacer las cosas → análisis de cómo hacemos las cosas → todos
comienzan a aportar ideas → es cuando menos productivo es el equipo
Igualmente aún no hay confianza y seguridad psicológica, por lo que
pueden surgir confrontaciones o roces en el equipo. pero vamos
construyendo las bases de la confianza en el equipo
3) Normalización → establecemos nuestras reglas, quien hace que, como,
etc
→ adquirimos el nivel de colaboración → todos trabajamos para un bien
común, un objetivo en común → ya nos conocemos, sabemos trabajar,
somos estables
4) Performing/Perfeccionamiento →se consolidan las relaciones entre los
miembros del equipo y las sinergias. Etapa de mayor rendimiento.-->
Todos pasamos a ser excelentes
5)
Los equipos pueden retroceder a otras etapas → cuando? viene un nuevo integrante,
cambiamos objetivos → lo que si no esta bueno que suceda es volver a etapa de
formación
El tema está en definir cuánto tiempo nos toma ir de una etapa a la otra No podemos
estar mucho tiempo en las dos primeras etapas
→ en las dos primeras no podemos estar mucho tiempo 2 o 3 meses → y la idea es si
volvemos a etapas solo ir pivotando entre la 2 y 3

Pero la mayoría de equipos se quedan en un bucle formación-confrontación → Cuando

llega la fase de confrontación, la gente rota, se va, la echan, se alargan las discusiones,
así que de una u otra los miembros del equipo dejan de ser los mismos, vienen nuevos, y
empieza de nuevo la fase de formación y luego vuelve a la de confrontación.
ejemplo de aplicación modelo Tuckman de Javier Garzás:
También menciona que usa este modelo a modo de retro: usando ese canvas, cada
miembro del equipo debe poner un post-it con una evidencia real, una situación
específica, que nos recuerde en qué fase del modelo está el equipo. Reflexionamos si
hay cosas que nos dejan en “confrontación” y definimos acciones para poder avanzar.

Cooperacion vs colaboracion
cooperacion → te ayudo pero no estoy comprometida con el objetivo
colaboración → te ayudo y conozco el objetivo y estoy comprometido con el

EQUIPOS AUTOORGANIZADOS

Management 3.0 -Jurgen Appelo (subrayado y comentado) - Capitulo 6

(pag 123 delpdf)

La gerencia dice el QUÉ y el equipo el COMO

Equipo auto-organizado → Es un equipo dirigido y organizado por sus propios

miembros, para alcanzar los objetivos especificados por la gerencia, dentro de las
limitaciones de su entorno.
Uno de los principios del manifesto nos dice que: “The best architectures, requirements,
and designs emerge from self-organizing teams.”

Los miembros deciden colectivamente y hacen lo necesario con el fin de cumplir con
los compromisos, desarrollar un producto de calidad, responder y adaptarse a los
cambios.

Entonces… la autoorganización significa que no hay jefes ni gerentes ni existe ningún

tipo de control o dirección en el equipo? No es tan así
Igualmente hay jerarquías más altas → estos dan los lineamiento los objetivos de la
organización → siempre tenemos que cumplir con los objetivos de la organización →
Siempre dentro de una empresa por mas que no haya jefes siempre hay alguien que
tiene más clara la visión sobre la empresa, o es quien la define
La gerencia puede dar forma y empujar al equipo, pero la dirección no dicta los detalles
de cuál es la solución ni el proceso de como crearla

El equipo es responsable no sólo de dirigir y organizarse para alcanzar sus objetivos,

sino también de controlarse y adaptarse para corregir y mejorar su propio desempeño.
Esto significa que el equipo puede cambiar la forma en que se dirige y organiza, con el
fin de responder a las limitaciones de su entorno
Que un equipo sea auto-organizado comprende que sea:

AUTÓNOMO, ADAPTABLE Y RESPONSABLE

➔ Autónomo → No existe un único centro de toma de decisiones o de autoridad. El

control se distribuye conjuntamente por todo el equipo → mientras mas madura
el equipo más autónomo puede llegar a ser (lo podemos relacionar con el
modelo de madurez de tuckman)
➔ Adaptable → Adaptarse a los cambios que surjan cambiar la forma en la que se
dirige y organiza con el fin de responder a las limitaciones del entorno → El
equipo se ajusta dinámicamente según sea necesario, con el fin de resolver sus
propios problemas y mejorar su propio desempeño.
➔ Responsable → El equipo comparte colectivamente la responsabilidad de los
resultados. → No puede ser autónomo si no es responsable
◆ → a veces al ser multifuncionales esperamos a que “seguro alguien mas
lo hace”, todos estamos esperando que alguien haga algo y así nadie hace
nada. → a veces puede terminar “tomando la posta” el menos capacitado,
solo por ser el más proactivo, pero es necesario saber la capacidad de
cada uno y en base a eso organizarse
◆ → La responsabilidad en agilidad incluye ser proactivos, no hacer solo lo
que nos dicen “para cumplir”, ir más allá (imposible si no tenemos equipos
motivados)

Auto-organizado vs Auto-gestionado
Los autores de la “Guia de Scrum” decidieron cambiar el término auto-organizado por
auto-gestionado. Exponiendo justificaciones como las siguientes:
➔ Ahora usamos el término auto-gestión para tratar de evitar que los equipos utilicen la
auto-organización como una herramienta para evitar cualquier compromiso. El
equipo se auto-gestiona para cumplir con sus compromisos para alcanzar los
objetivos.
➔ La auto-organización se malinterpretó ampliamente en el sentido de que los
desarrolladores ágiles no tienen que cumplir compromisos. Esperamos que la
autogestión cree una actitud más madura hacia la satisfacción de las necesidades
de la organización.

Modelos de Liderazgo y Auto-Organización

Equipo Clasico → Modelo “Control y Mando”
Basado en cómo en la gestión militar → tengo una gerencia que decide cómo hacer y
que hacer, abajo solo acatan ordenes, ejecutan sin pensar → management 1.0

Llevado al mundo del desarrollo:

Hay una pirámide organizacional dentro del equipo: un Jefe de Proyecto que nos dice que
vendemos, como y quien participa. Los mandos intermedios con jefes de cada área, y la
parte operativa que sólo acatan órdenes y ejecutan.
Problemas → Una orden no es ejecutada igual por todos, falta de creatividad e
innovación, problemas de comunicación, las decisiones son centralizadas.

Ya sabemos que no podemos tratar igual a un equipo en el ejército, que alguien que
realiza trabajo intelectual:
➔ Problema #1 -> En el ejército es posible dar a mucha gente una misma orden, en
desarrollo una misma orden puede tener múltiples interpretaciones o maneras de
ejecutarlas
➔ Problema #2 -> En equipos de SW el conocimiento no siempre está en los
gestores. Lo más probable es que el management no conozca todos los
aspectos técnicos, el conocimiento lo tienen quienes hacen las cosas
➔ Problema #3 ->En SW equipos más numerosos, son menos productivos (muchos
canales de comunicación, etc) → se pierde mucho tiempo poniéndonos de
acuerdo o tomando decisiones
En sistemas complejos, como el trabajo de un equipo de desarrollo, no solo la
auto-organización es una buena práctica, sino que se da por default. por más que el
management intentara dirigir y controlar, siempre va a haber autoorganización.Siempre las
personas van a discutir entre ellos y estar de acuerdo o no, hablan en los breaks o en otros
eventos. El tema está en cómo sabemos si están yendo en la dirección “correcta”.

LIDERAZGO EN EQUIPOS AUTO-ORGANIZADOS:

Pero en equipos auto-organizados, no existe un único lider del equipo durante la vida útil del
equipo o proyecto. El «líder» no es una asignación estática, sino más bien un papel
dinámico.Así que la persona que dirige el equipo en un momento dado puede cambiar,
dependiendo de la actividad o problema que se aborda en un contexto o situación particular.

Como dijimos, ser autoorganizados no significa que no haya jerarquías más altas, pero que
estos personajes deben ser vistos desde otra perspectiva. Por lo que la agilidad propone:

Caracterización de Liderazgos:
LÍDER VS JEFE → El líder acompaña con el ejemplo, el jefe da órdenes y no se involucra.

➔ SUPER LEADER
Mantiene características del liderazgo tradicional, mantiene la pirámide de liderazgo
tradicional; pero ya está más presente el concepto de acompañar, no solo dar órdenes. No
es completamente ágil pero se acerca.
Si estamos buscando la auto-organización, ese “empowerment”, esa aportación e
inteligencia colectiva, etc., esta figura no es exactamente lo que queremos en agilidad.
➔ SERVANT LEADER
El líder está al servicio del equipo. Damos vuelta la pirámide, y en vez que el líder está arriba
de todo, está abajo. Se encarga de que el equipo tenga todo lo que necesite para poder
hacer su trabajo. Más enfocado en la agilidad
Es el modelo que vemos en el caso de Spotify. Y en realidad ya se habla de ellos en Scrum,
ver al SM y PO como servant leaders del equipo.

Para algunas situaciones esta metáfora puede ser muy útil, pero, ¿qué pasa si la gente actúa
en una dirección cerrada, opuesta, con comportamientos tóxicos que no son buenos para el
equipo? ¿Cómo yo, como sirviente, reoriento al equipo para cambiar su comportamiento, si
no tengo autoridad ninguna? Y si tuviera autoridad, ¿cómo guío al equipo adecuadamente
sin caer otra vez en un mando y control?
➔ HOST LEADER
I'm Not a Servant - I'm a Host! A New Metaphor for Leadership in Agile?
Organiza todo y permite que luego el equipo pueda funcionar sin necesidad de que el esté
presente controlando y dirigiendo. No está en el centro del equipo. Si surge un problema
podemos ir con el líder.

Es como ser el anfitrión de una fiesta, preparamos todo, nos aseguramos de crear un buen
entorno, que el lugar esté lindo, haya música, comida, bebida. Luego cada invitado se
divierte y hace lo que quiere, pero si necesita algo , algo falta o no funciona, va con el
anfitrión a pedirle ayuda.
Después de organizar un evento, un buen anfitrión no lo monopoliza, más bien va de un sitio
a otro comprobando que todo va bien, sin ser el centro de atención o estar siendo siempre el
protagonista.
Liderar al equipo ágil no se trata sólo de servir, y darle todo lo que ellos requieran, pero sino
de entender el contexto del equipo y darle lo que este necesita.
Pero además, los anfitriones también tienen ciertos derechos: decidir quién viene y quién no,
o incluso establecer una serie de normas y límites, asegurarse de que la gente los cumpla y
si no tomar acciones en consecuencia, como echar a alguien de la fiesta por faltar el respeto
a otra persona.
➔ GUEST LEADER
Normalmente no es el líder, o no es un líder fijo, pero en ocasiones toma el liderazgo. Si
tengo las capacidades necesarias para ese momento en esa situación, asumimos el
liderazgo hasta resolverlo.
Definir líderes o responsables para las cosas importantes que tenemos que hacer.
Retomando el ejemplo de organizar una fiesta, el guest leader sería cuando un invitado nota
que hay que hacer algo, participar, ayudar, etc., y voluntariamente, sale de él, y se encarga de
ello, en lugar de esperar a que el anfitrión aparezca.
TOMA DE DECISIONES
Se entiende que la auto-organización es que se cede al equipo la toma de decisiones,
frente a la estructura más clásica de que sea alguien externo el que decida por el equipo
(típicamente esa figura era el jefe de proyecto).

Tomar una decisión te compromete más con ella que si la decisión viene dada por otra
persona. Participar en la toma de decisiones genera sentimiento de pertenencia con la
decisión. El sentimiento de realización se incrementa cuando las decisiones las toma el
grupo, frente a una persona externa.

En un equipo auto-organizado la toma de decisiones se hace por consenso, con la

participación de todo el equipo. Esto no significa que “hacemos lo que todos quieren” o
“siempre todo el mundo decide todo”, no nos ponemos de acuerdo en la decisión nos
ponemos de acuerdo en que definimos como equipo como consenso.

En cuanto a la idea de que TODO el equipo participa en TODAS las decisiones:

Esto puede traer algunos problemas, dependiendo de la madurez del equipo, pero sobre todo
en nuevos equipos podemos destacar:
➔ se puede tener mucho desperdicio al tener que juntar a todo el equipo siempre para
tomar todas las decisiones. Hay ceremonias que requieren de todo el equipo, como
los “planning”, pero si, además, para cada decisión hay que juntar a todo el mundo…
➔ Pone al mismo nivel las decisiones de perfiles senior y junior (hasta de becarios).
Esto, de nuevo, puede ser desperdicio, e, incluso, puede desmotivar a los perfiles
senior que ven cómo su criterio está al nivel, pesa lo mismo que el de algún miembro
muy junior.

Otro problema que pueden surgir de la auto-organización:

Todos, cualquier miembro del equipo, puede hacer cualquier cosa… pero resulta que nadie
la hace, todo el mundo pensaba que alguien lo haría, pero nadie lo hizo. No hay un
responsable, somos muchos… pero realmente ninguno -> Que las tareas las pueda hacer
cualquiera no quiere decir que no tengan responsable de qué se haga o resuelvan.

Una práctica que nos puede ayudar con esto son los tableros de delegación

Delegation Boards:
Práctica propuesta por el Management 3.0 de Appelo.

Este tablero propone 7 categorizaciones en la toma de decisiones. Este tablero se debe

definir en equipo. Entre todos decidimos de que manera tomamos las decisiones y quien lo
hace.
Hasta la columna 3 y medio, la responsabilidad de la decisión es del líder o jefe. De ahí en
adelante el equipo toma más protagonismo

Nivel 1→ TELL → jefe o líder toma decisiones sin consultar a nadie, solo informa la
decisión
Nivel 2 → SELL → El líder intenta vender la idea → Toma la decisión pero intenta que el
equipo esté de acuerdo con la decisión que se tomó
Nivel 3 → CONSULT → Preguntó al equipo cuáles son sus opiniones y en base a esto el
jefe/lider tomó la decisión
Nivel 4 → AGREE → Tomamos la decisión entre todos
Nivel 5 → ADVISE → El equipo le pide la opinión al jefe o líder, y toma la decisión el
equipo en base a eso
Nivel 6→ INQUIRE → Toman la decisión y se la comunican al jefe o líder
Nivel 7 → DELEGATE → El equipo toma decisiones y no tiene que avisarle al jefe o lider
Ejemplo de aplicación de un tablero de delegación en 233:

Vemos que no se usan las primeras tres columnas → no hay jefe, tomamos las
decisiones entre todos ((vbollati es batman))
MATERIAL USADO:
Libros → carpeta drive con toda la bibliografía
Introducción a la agilidad:
⭕ ¿Qué es la AGILIDAD? Keynote en el Banco BBVA
¿Qué es Agilidad? frameworks, manifiesto y algunas fechas
3 Décadas de Historia e historias de la Agilidad por Alistair Cockburn (1/2)

🤙
Movimiento #NoEstimate:
[DIRECTO] ¿Estimar o no estimar? #noestimates con Javier Garzás
Vasco Duarte: NoEstimates
No estimar (noestimates): recopilación de referencias, información, para seguir
aprendiendo, etc.
Estimación ágil: #NoEstimates (1)
“Por qué los puntos historia son peligrosos” -Javier Garzás
#NoEstimates Part 1 — Doing Scrum Without Estimates | by Neil Killick | Medium
'No Estimates: Let's Explore the Possibilities' by Woody Zuill
Heart Of Agile:
cockburn - presentacion-theaheartofagile.pdf
Material escrito: The Heart of Agile → 201611-Cockburn.pdf
Kammi: https://kami.app/PLs-Vwx-WFK
Video: VIDEO: Agil ophavsmand besøgte Danmark
Escalando Agilidad:
Fina Pérez (@finuka) - Being agile, Tuenti style
Spotify Engineering Culture (by Henrik Kniberg)
Spotify Engineering Culture - Part 2
Resumen: SPOTIFY ENGINEERING CULTURE.pdf
Scaling Agile @ Spotify with Henrik Kniberg
https://www.javiergarzas.com/2018/06/no-caigas-error-copiar-modelo-agil-spotify.html
#comment-18322
SAFe:(aka el tema mas aburrido del mundo)
Agile Modeling:
http://agilemodeling.com/
Caso de Exito: Ferrovial, Design Thinking en entornos de Big Data -profeMariano
Agile Modeling -Scott Ambler.pdf
Crystal Clear:
Alistair Cockburn - Crystal Clear A Human-Powered Methodology for Small Teams A Hu…
//estos conceptos hoy en dia ya son muy basicos, si leer sobre las practicas mencionadas
Agile Coaching
(Addison-Wesley Signature Series) Lyssa Adkins - Coaching Agile Teams_ A Companio…
Algunos consejos sobre el rol del Agile Coach
La guía del Agile Coach (post recopilatorio y vivo)
Coaching: Todo lo que necesitas saber del Coach
 🤙 [DIRECTO] ¿Coaching como herramienta Ágil? Directo con Ángela Rueda
https://www.javiergarzas.com/2018/12/algunos-consejos-sobre-el-rol-del-agile-coach.html
https://www.javiergarzas.com/2018/12/guia-del-agile-coach.html
https://www.javiergarzas.com/2016/07/introduciendonos-al-mundo-del-coaching.html
https://www.javiergarzas.com/2016/07/coaching-lo-necesitas-saber-del-coach.html
https://www.javiergarzas.com/2019/03/usamos-agile-coach-para-resolver-lo-que-no-saben-hacer-
los-scrum-master.html
https://www.javiergarzas.com/2017/09/tu-agile-coach-visto-como-un-personal-trainer.html
https://www.javiergarzas.com/2019/07/el-error-de-encasillar-nuevas-profesiones-en-otras-mas-an
tiguas-agile-coach.html
https://www.javiergarzas.com/2014/12/agile-coaching-scrum-master.html
Management 3.0
Addison.Wesley.Management.3.0.Jan.2011.ISBN.0321712471.pdf -Capitulo 5 y 6
Jurgen Appelo - Merit Money.pdf
humansideofenterprise.pdf
Frederic Laloux - Reinventing Organizations-Nelson Parker (2014).pdf -Parte I
Dave Logan - Tribal Leadership Leveraging Natural Groups To Build A Thriving Organizati…
-Parte I y II
Managing for Happiness | Jurgen Appelo | TEDxLille
Jurgen Appelo - Keynote Management 3.0
Jurguen Appelo - Workout 3.0 (solo lo tengo en epub)
Management 3.0 Leadership Training for Managers
Peopleware:
PeopleWare: Productive Projects and Teams -DeMarco.pdf
¿Qué motiva a las personas de un equipo? (1/2)
¿Qué motiva a las personas de un equipo? (2/2)
La Teoría X (gestión industrial) y la Y sobre la motivación (1/2)
Factores de motivación intrínseca...
Sobre la motivación por recompensas y el experimento de la vela
Tipologías de equipos software (I). El equipo “Control y Mando”
https://www.javiergarzas.com/2020/09/equipos-agiles-y-peopleware-modelo-tuckman-en-vi
deo.html
https://www.iapm.net/en/service/literature/tom-demarco-slack/
https://www.javiergarzas.com/2013/10/slack.html
Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency -DeMarco(solo lo
tengo en epub)
Equipos Agiles
El equipo ágil auto-organizado
Un equipo Ágil está formado por personas cuyos valores personales también son Ágiles
Tipologías de equipos software (IV). El equipo ágil
https://www.javiergarzas.com/2018/07/equipos-agiles-el-dificil-cambio-del-yo-al-nosotro
s.html
New Agile: La necesidad de líderes con responsabilidad... y no sólo una libre
auto-organización / auto-gestión
https://www.javiergarzas.com/2015/04/las-disputas-y-discusiones-son-una-constante-en-tu-
equipo-entorno-de-trabajo-no-te-preocupes-no-estas-solo.html
No queremos ser equipos auto-organizados
La auto-organización es un viaje de madurez
La auto-organización no implica que, necesariamente, todo el equipo decida todo
Algunas razones por las que deberías persistir en la idea auto-organización
Equipos auto-organizados (I/II). “Arma” poderosa, pero también peligrosa (si no se usa bien)
https://www.javiergarzas.com/2018/11/la-auto-organizacion-no-necesariamente-que-todo-el
-equipo-decida-todo.html
https://www.javiergarzas.com/2015/04/lideres-agiles.html

+notas de clase

https://www.javiergarzas.com/2015/01/26-mejores-libros-sobre-gestion-agil-y-temas-a
fines.html

https://colorhunt.co/palette/4b3869664e8863b4b8a9e4d7
https://colorhunt.co/palette/22577a38a3a557cc9980ed99
https://colorhunt.co/palette/f3f1f5f0d9ffbfa2db7f7c82

Titulos → #d2f2cdff

Secciones:
➔ Checklist de temas que estan en el apunte
➔ Material usado en cada titulo
➔ En cada titulo tambien hay referencias de que capitulos se uso si era un libro,
o notas de videos
➔ Seccion de resumen
➔ Preguntas AutoEstudio

UNIDAD 1
Introducción a la agilidad
Movimiento #NoEstimates
How to fail with agile
Escalando Agilidad - Transformación ágil
Frameworks Escalabilidad
SAFe
Tuenti
Spotify
Antes de agilidad:
Crystal Clear -Alistair
Agile Modeling
Lo nuevo en agilidad:
 Heart of Agile -Alistair
Agile Coaching
Pros y Contras de Certificaciones Agiles

UNIDAD 2
Management
1.0
2.0
3.0

Complexity Thinking
Comunicación
Toma de Decisiones
Seguridad Psicológica
Prácticas
Tucker
Prueba de Weinberg
Team Barometer
Alianza de equipo y de equipos
Lean Coffe
Peopleware
Equipos
Multifuncionalidad
Auto-Organización
Motivación
Extrinseca vs Intrinseca
Técnicas
Empower Teams
Practicas
Moving Motivators
Happiness Door
Happiness Index
Snap
Merit Money
Productividad en el equipo
Espacios de Trabajo
Como ser productivos
Manejo del tiempo
Crucnh mode
Slack
Ritmo Sostenible
Que frena nuestra productividad
Align Constraints
Valores y cultura
Develop Competence
Practica
Retrospectives
Improvement
Gestión del cambio
Lean Change