1

Playbook Assessment (versión 5.6)

Acerca del Assessment del Playbook

El Assessment del Playbook es una actividad que puede ser ejecutada de distintas maneras y en
diferentes etapas del desarrollo del Equipo.

● Forming Assessment: generalmente es ejecutado por el mismo equipo o por un facilitador

externo durante la etapa de forming del equipo. El objetivo principal de este assessment
es concientizar al equipo acerca de los Principios. Una reacción común de los miembros
del equipos es:

" No sabía que no sabía… ahora sé que no sé"

Vamos a entender algunos conceptos:

● Llamamos Principios a los 11 ítems que han sido identificados por el equipo/squad. Son
principios guía, no se supone que sean un checklist, pero sí son una lista de cosas que son
relevantes y que son buenas para pensar cuando se está en un equipo/squad.
● Cada principio tiene un conjunto de Criterios que son áreas de atención para que el equipo
tenga conciencia de ellos.
● Cada Criterio tiene Señales: pueden ser Buenas Señales o Señales de Mejora. Una vez
más, las señales no son un checklist, de hecho, el identificar Señales de Mejora es uno de
los objetivos del Assessment.

2
Playbook Assessment Canvas

3
Recomendaciones previas para realizar el assessment:
- Debe estar al menos el 80% de los integrantes del Squad.
- Tener las cartas con los principios del PlayBook ordenadas por cada Gate de madurez.
- Llevar un juego de cartas para cada uno de los equipos que se conforme.
- Dividir el Squad en grupos de 5 personas (Aproximadamente)
- Dar a cada integrante del Squad un post-it rojo, naranja y verde.
- Imprimir el Canvas en tamaño pliego y pegarlo en un lugar visible para todos.
- Llevar las cartas del PlayBook en inglés y español, por si no todos los miembros del Squad hablan
español o inglés.
- Tener un TimeBox visible.

Pasos sugeridos para realizar el Assessment:

1. Dar contexto a todos lo miembros del Squad sobre cúal es el propósito de realizar el Assessment.
2. Proyectar video de la madurez de los Squads.
3. Contar acerca de los otros Squads que han realizado el Assessment y en qué nivel se encuentran.
4. Hacer acuerdos sobre cómo será la dinámica de la reunión (contestar llamadas, usar
computadores, votación, tiempos, etc...)
5. Dar juego de cartas a cada equipo dependiendo del Gate a evaluar.
6. Dar un minuto para que lean el principio y debatan en cada equipo sobre las señales.
7. Pasado el minuto, pedir a todos los miembros del Squad que “voten” con sus Post-it de color
(verde, naranja, rojo) en qué estado consideran que se encuentra el principio que está siendo
evaluado (importante que todos voten al mismo tiempo, para que no se influencie la votación).
8. Si hay consenso en el color de votación, se pregunta a cualquier persona del Squad porqué
considera que está de ese color el principio.
9. Si hay diferencias en la votación, se le pregunta a cualquiera de las personas que votaron
diferente el porqué de su voto.
10. Cuando ya hay consenso entre el Squad y el Coach en el color asignado al principio, se pega el
principio en el Canvas en el color que corresponda y si existe alguna acción de mejora
identificada se pregunta al equipo quién tendrá el Ownership de esta tarea.

4
Madurez

5
La Tabla de Principios del Assessment
Haciendo click en cada Principio del Playbook, irás a los Criterios y Señales asociados.

1 2 3 4
_ _ _ _
Entender las BML Equipo Estable y Negocio y
Necesidades del (Build-Measure- Multidisciplinario Tecnología
Usuario Learn) Trabajan Juntos

5 6 7 8
_ _ _ _
Equipo Parte de Outcome Innovación
Autónomo Algo Mayor sobre Output Incorporada

9 10 11
_ _ _
Claridad Estratégica Búsqueda de la Medir las
y Alineamiento Excelencia Técnica Cosas Correctas

6
1
_
Entender las Necesidades del Usuario
Buscar entender las necesidades del usuario a través de
técnicas como UX, XD y Service Design, de manera de
entregarle experiencias memorables, sin obstáculos y
esfuerzos; dentro y entre canales.

ㅡ
Creemos que los POs (en conjunto con los UX,
1.1 Preparación para la stakeholders, analytics, etc.) deben venir a la Inception
Inception preparados con un punto de vista asociado a una
definición priorizada del alcance (hecho a través de
discovery y alineado con el sponsor del producto) y no
que está creada “al vuelo” con el equipo completo
durante la Inception,

Buenas Señales Señales de Mejora

- Durante la - Durante la
Inception ya Inception no tuvimos
sabemos las suficiente
necesidades del información del
usuario y los usuario (cualitativa y
caminos a recorrer. cuantitativa), por lo
que fue más difícil
tomar decisiones.

7
ㅡ
1.2 Service Design Continuo Continuamente buscamos entender las necesidades del
(UX/ XD) usuario a través de técnicas de UX, XD y Service Design.

Material de lectura:
● What is Discovery?
● Discovery from Day One
● 5 cognitive traps to avoid in Discovery
● ¿Tienes más contenido? Por favor agrega un
comentario aquí y así podremos incorporarlo

Buenas Señales Señales de Mejora

- Entendemos muy - No hablamos muy

bien el perfil y seguido con
necesidades de nuestros usuarios.
nuestros usuarios. - Tomamos
- Constantemente decisiones basadas
tratamos de validar en lo que piensa
nuestro nuestro PO, más que
conocimiento en lo que hemos
acerca de nuestros descubierto a través
usuarios y sus de user research.
necesidades, en
caso que hayan
cambiado.

8
ㅡ
1.3 Multi-Canal y No-Digital Experiencias para el cliente sin obstáculos, sin esfuerzos
y de alta calidad; dentro y entre canales.
Creemos que es importante entender la experiencia de
usuario completa y no sólo en un canal o producto. Es
esencial la colaboración entre los equipos, de manera
de entregar experiencias memorables a los usuarios.
Asimismo, es importante mapear las dependencias y
tener consistencia de la experiencia a través de los
canales,sin olvidar la experiencia no-digital.

Buenas Señales Señales de Mejora

- Durante nuestra - Sólo miramos

fase de discovery, nuestro canal, los
tratamos de demás no son
entender todos los nuestro problema.
caminos del usuario - Somos un equipo
incluyendo aquellos de desarrollo, por lo
no digitales. que la experiencia
- Los usuarios están no digital es
satisfechos con su preocupación de
experiencia a través otros.
de múltiples - Los usuarios están
canales, incluyendo confundidos con
los no digitales. experiencias
- Hablamos con inconsistentes a lo
otros equipos para largo de los
entender la múltiples canales.
experiencia del
usuario en
diferentes canales.
- Se hizo el ejercicio
de validar con qué
canales podemos
satisfacer las
necesidades del
usuario.

9
2
_
BML (Build-Meassure-Learn)
Usar los valores, principios y prácticas de las ya consolidadas
metodologías Agile y Lean. Entregar valor, continuamente,
reconociendo y eliminando desperdicios.

ㅡ
2.1 Eliminar Desperdicio Reconocemos y eliminamos desperdicio
constantemente. Creemos en la simplicidad, el arte de
maximizar la cantidad de trabajo no hecho. El eliminar
desperdicio se encuentra en el corazón del desarrollo
de software Lean.

Material de lectura:
● The Seven Wastes of Software Development

Buenas Señales Señales de Mejora

- Durante nuestras - ¿Desperdicios?

retrospectivas, ¿Qué son los
hemos identificado desperdicios?
desperdicio y lo - ¿Lean Software?
hemos trabajado y Pensábamos que
mejorado. Lean era un término
- Constantemente de manufactura.
estamos atentos a - ¿7 Desperdicios?
los 7 tipos de Nunca los habíamos
desperdicio para así escuchado.
eliminarlos.

10
ㅡ
2.2 Scrum y Otros Creemos que, por defecto, los equipos entregarán a
través del framework de Scrum, pero si hay alguna
razón para variar, todos son bienvenidos a plantear
recomendaciones alternativas en su equipo, quienes en
conjunto brindarán el soporte para probarlas o
cambiarlas. Animamos a los equipos a modificar las
ceremonias para que trabajen con sus propias
dinámicas, siempre y cuando, sigan consiguiendo el
objetivo de la ceremonia. Algunas alternativas a Scrum
son: Kanban y Scrumban. Si nunca has probado ninguno
de estos 3, recomendamos comenzar con Scrum y
mejorarlo continuamente.

Material de lectura:
● Awesome Agile Links
● What is Scrum?
● Atlassian - no-nonsense guide to agile
development
● Examples of Retrospectives and others

Buenas Señales Señales de Mejora

- Nosotros - No tenemos
comenzamos realmente un
usando Scrum. proceso.
- Después de alguna - No hemos
retrospectivas, cambiado nada
hemos cambiado desde que
algunas cosas. comenzamos.
- Usamos Kanban - La verdad es que
porque creemos no sabemos cuál
que es mejor que proceso usamos.
Scrum.

11
ㅡ
2.3 MVPs Creemos que el verdadero “MVP” (Minimum Viable
Product) es el menor entregable que podemos construir
y dejar en manos del usuario para que nos dé señales
que permitan validar o bien invalidar una
hipótesis/experimento.
Sin embargo, en el contexto de los equipos, un “MVP”
debería ser una funcionalidad que pueda ser liberada
independiente a producción, satisfacer una necesidad
del cliente y llevar algo de valor para el negocio. En este
contexto, un MVP no debería tomar más de 3 o 4 sprints
para ser construido.

Buenas Señales Señales de Mejora

- El equipo y el PO - Sólo existe un gran

tienen claridad de release al final.
qué MVPs han sido - Los usuarios
planificados y qué esperan meses para
características ver algo nuevo en
componen a cada producción.
uno de ellos. - No sabemos cómo
- Los entregables se quebrar el release
han quebrado en en MVPs.
múltiples MVPs que - Existen fechas
se implementan de inamovibles de
forma iterativa en entrega.
producción.
- El squad entrega el
mínimo requerido
para recopilar
feedback en
producción del
usuario.

12
3
_
Equipo Estable y Multidisciplinario
Formar equipos desarrollados de larga duración con las
capacidades y el tamaño necesario para que trabajen a un
ritmo sostenible.

ㅡ
Creemos que podemos maximizar el desempeño y el
3.1 Equipo co-localizado compromiso de entrega del equipo cuando sus
miembros están co-localizados y, de hecho, es nuestro
enfoque preferido. Sin embargo, estamos abiertos a las
excepciones, ya que nos damos cuenta de que no
siempre es posible y, en aquellos casos,
implementamos rotaciones o virtual overlap window,
usando herramientas de tecnología (por ejemplo, video
conferencias).

Buenas Señales Señales de Mejora

- El equipo se sienta - Las personas no se

junto. hablan con
- Todos los frecuencia.
miembros del - Las herramientas
equipo se hablan en para la
el día a día. comunicación
- Los equipos no se necesitan ser
sientan juntos en el mejoradas.
día a día, pero la
comunicación no es
un problema, ya que
nuestras
herramientas son
increíbles.

13
ㅡ
Creemos que es mejor comenzar con un equipo
3.2 Tamaño del equipo pequeño (menos es más) y que crezca a medida que
sea necesario. Nuestro tamaño ideal del squad base no
es mayor a 9 personas y menor a 5 personas. Lo
llamamos “7 más/menos 2”. Pueden haber ciertas
excepciones que serán evaluadas según corresponda.

Buenas Señales Señales de Mejora

- El tamaño del - El tamaño del

equipo/squad está equipo es menor a 5
es entre 5 y 9 o mayor a 9
personas personas.

ㅡ
3.3 Equilibrio entre vida y
Apoyamos y promovemos el balance entre trabajo y
vida de nuestros colaboradores. Creemos que cada
trabajo
equipo determina qué es mejor para ellos en relación a
la flexibilidad y el sentido de urgencia.

Buenas Señales Señales de Mejora

- Los miembros del - Los miembros del

equipo/squad están equipo sienten que
comprometidos y existe demasiada
ocupados, pero no presión.
muy cansados. - Los miembros del
- Existe un sentido equipo trabajan
de urgencia, pero no muchas horas, fines
tanta presión como de semana y
para derribar al feriados.
equipo/squad..

14
ㅡ
No existe un “jefe”. Creemos que no hay jerarquía dentro
3.4 Sin Jefes
del equipo - ni el TL, ni el IM, ni el PO es el “jefe” del
equipo.

Buenas Señales Señales de Mejora

- Los miembros del - Algunos miembros

squad se dan del equipo se
feedback de manera comportan como
mutua, jefes, dando
independiente de su órdenes y tratando
rol. al resto como
- Los líderes son subordinados.
servidores y no
jefes.

ㅡ
3.5 Traer trabajo a la gente,
no gente al trabajo
Crear equipos estables, de larga duración y siempre con
diferentes tipos de trabajo, en vez de crear y destruir
equipos para diferentes piezas de trabajo o proyectos.

Creemos que existe un enorme costo en crear un

equipo. El equipo pasa por fases de Forming, Storming,
Norming y Performing. Uno de los activos más valiosos
que una organización puede tener es un "Equipo de Alto
Rendimiento". Construirlo y cultivarlo.

Buenas Señales Señales de Mejora

- El mismo squad - Los miembros del

existe por un largo equipo van y vienen
periodo, algunos frecuentemente.
miembros se han ido - El equipo entero se
y otros se han unido, crea y se destruye
pero el squad base por cada iniciativa.
se ha mantenido.

15
ㅡ
Creemos que los integrantes de un equipo deben estar
3.6 Dedicación
100% dedicados. Cada equipo también aprovechará la
capacidad y la experiencia de los referentes externos
(equipo extendido).

Buenas Señales Señales de Mejora

- Dev Team están - El Scrum Master es

dedicados 100% a parte de muchos
un squad. equipos.
- Otras capacidades - Varios de los
son solicitadas a miembros del
medida que son equipo son parte de
necesarias. más de un equipo.

ㅡ
Apoyamos y promovemos el balance entre trabajo y
3.7 Ritmo Sostenible
vida personal de nuestros colaboradores. Creemos que
cada equipo determina qué es mejor para ellos en
relación a la flexibilidad, las políticas de trabajo desde la
casa y cuándo es necesario el sentido de urgencia.

Buenas Señales Señales de Mejora

- Los miembros del - Los miembros del

equipo/squad están equipo sienten que
comprometidos y existe demasiada
ocupados, pero no presión.
muy cansados. - Los miembros del
- Existe un sentido equipo trabajan
de urgencia, pero no muchas horas, fines
tanta presión como de semana y
para derribar al feriados.
equipo/squad.

16
ㅡ
El equipo contiene todos los roles necesarios para
3.8 Equipo Multidisciplinario
poder minimizar las dependencias externas en la
entrega de valor.

Buenas Señales Señales de Mejora

-Los roles -El equipo está

necesarios para frecuentemente
entregar valor en la bloqueado por no
mayoría de los tener skills
casos, están dentro necesarios.
del equipo.
-El equipo no puede
-El equipo no tomar algunas
necesita gestionar historias por falta de
recursos externos capacidad.
para cubrir sus
necesidades.

17
ㅡ
Aplicamos el modelo 70-20-10 para roles. Cada
3.9 Personas con forma de T
miembro del squad juega diferentes roles en diferentes
(T-shaped) momentos, idealmente, distribuyendo su tiempo de esta
forma:
- 70%: El rol que alguien toma la mayoría del
tiempo, es aquel rol para el que es mejor.
- 20%: El rol que el miembro del equipo puede
tomar, está aprendiendo y quiere desarrollar.
- 10%: El rol que quiere desarrollar, quiere intentar y
que nunca ha tomado antes.

Por ejemplo, alguien podría ser: 70% Dev + 20% TL + 10%

IM.

Buenas Señales Señales de Mejora

- El TL es también - Cuando un
backup del IM. miembro del equipo
- El PO también es está ausente, el
backup del UX y del equipo se
BA cuando es descompone por la
necesario falta de ese rol.
- El Dev también es - Cada miembro del
QA. equipo tiene un rol y
- Cuando un nunca experimenta
miembro del squad algo diferente.
no está, el squad
siempre tiene otros
miembros que
pueden suplir ese
rol.

18
ㅡ
El equipo debe tener la responsabilidad sobre la
3.10 Tú lo construyes, tú lo
construcción de nuevas características para un
operas producto, así como mantener sus productos en
producción. Esto permite a los miembros del equipo ser
conscientes y responsables de las consecuencias de
sus acciones, es decir: si construyes algo que se rompe,
lo arreglas.

Material de lectura:
● From Amazon
● Amazon CTO Interview
● There is No Such Thing as a "Devops Team"

Buenas Señales Señales de Mejora

- Los problemas en - Un equipo

producción son desarrolla, otro
resueltos por el implementa, otro
mismo mantiene en
equipo/squad que producción.
los desarrolló. - Un equipo arregla
- El mismo squad los errores creados
posee el ciclo de por otro equipo.
vida completo de - Un equipo
una característica mantiene lo que
- Para cada otro equipo
producto, el equipo desarrolló.
que lo construyò
sigue existiendo.

19
4
_
Negocio y Tecnología Trabajan Juntos
Las personas que tienen capacidades de negocio, de usuario y
de tecnología trabajan juntas en el día a día.

ㅡ
Creemos que el PO debe sentarse con su equipo de
4.1 Dedicación del PO entrega, pero no estará disponible para ellos en ese
lugar todo el día ni todos los días (debido al tiempo que
necesita para acercarse al cliente, a sus stakeholders, a
los expertos (SME) y para hacer análisis cuali y
cuantitativo). Esperamos que pueda asistir a todas las
ceremonias. El PO es alguien del negocio.

Buenas Señales Señales de Mejora

- Hay un PO - El PO no participa
dedicado al de nuestras
equipo/squad y es reuniones diarias ni
del negocio. de nuestras retros.
-El PO está -Hay un PO
empoderado para dedicado al equipo
tomar decisiones. pero no es del
negocio.
-El equipo está
bloqueado por la
dependencia del PO

20
ㅡ
Creemos que todo equipo/squad que está trabajando
4.2 Negocio y Procesos sobre algún producto debe tener un Business Owner y
operativos Business Sponsor provenientes del negocio. Su rol y
responsabilidad es financiar y ser un partícipe activo del
producto que se está desarrollando y creando. Deben
actuar no sólo como indicadores de KPI’s , sino ayudar a
destrabar ciertos problemas que el equipo pueda tener
en su desarrollo y al mismo tiempo ser un agente que
promocione el trabajo que se realiza con sus pares del
negocio.

Buenas Señales Señales de Mejora

- Business Owner - Business Sponsor

participa no conoce ni
activamente con el participa con equipo
equipo/squad y en instancias claves
asiste a ceremonias. como inception,
reuniones
- Business Sponsor mensuales etc.
acude a reuniones
mensuales a las -Business Owner no
cuales ha sido aparece en las
invitado y ayuda a ceremonias a las
evangelizar y que fue invitado ni
promover el trabajo genera feedback; el
realizado. contacto con el
negocio se va
-Business Sponsor y diluyendo poco a
Business Owner poco.
proveen datos y
KPI’s de negocio - El Business Owner
útiles para el da requerimientos al
equipo/squad junto equipo.
con alineamiento de
negocio con - El Business Owner
respecto a los no da feedback
productos durante las
trabajados. demos.(Feedback
Demo.)
-Business owner
ayuda en la
estrategia de
negocio, los KPI’s y
el impacto
operativo

21
5
_
Equipo Autónomo
Cada squad tiene autonomía para tomar decisiones que
tendrán impacto sobre ellos mismos; considerando a otros
equipos/ squads cuando las decisiones los impactan.

ㅡ
Creemos que el PO representa al cliente final y a los
5.1 Aprobación para stakeholders de negocio, y como tal, su aprobación es
producción todo lo que se necesita para que una historia sea
“completada” y desplegada en producción.

Buenas Señales Señales de Mejora

- La aprobación del - Necesitamos

PO es todo lo que obtener aprobación
necesitamos para de otros niveles,
desplegar algo en fuera del equipo
producción. para poder
implementar en
producción.

22
ㅡ
El squad debería tener suficiente autonomía para tomar
5.2 Autonomía de decisión la mayoría de las decisiones relativas al diseño,
implementación y operación de sus productos, así como
su roadmap

Buenas Señales Señales de Mejora

- La mayoría de las - La mayoría de las

decisiones son decisiones son
tomadas por el tomadas por
squad y no requieren alguien externo al
mucho tiempo. equipo, toman
tiempo y retrasan al
equipo.

23
6
_
Parte de Algo Mayor
Ser consciente de que eres parte de un ecosistema mucho
mayor junto a otros equipos/ squads, stakeholders y
dependencias.

ㅡ
Existe una PMO en la organización que aplica principios
6.1 Portafolio priorizado por de Lean PMO, la cual orquesta qué productos serán
valor priorizados para ser tomados por el squad. Se necesita
que haya alineamiento y consciencia por parte del
squad con esta entidad global.

Buenas Señales Señales de Mejora

- El squad participa - ¿Lean PMO? ¿Qué

activamente de los es eso?
procesos definido
por la Lean PMO. -Equipo decide
autónomamente en
-El equipo siempre qué producto
está trabajando trabajar.
sobre las
priorizaciones
definidas por la
Lean PMO

-El único punto de

entrada de carga de
trabajo, está
dictaminado por el
proceso de Lean
PMO.

24
ㅡ
6.2 Ecosistema de Tribes Creemos que existe valor en la coordinación entre
squads, dado el número de dependencias que hay
dentro de nuestra organización, y a lo largo de nuestros
productos y stack tecnológico. Así, animamos a los
squads a participar en un Ecosistema de Tribes donde
se gestionan las dependencias y riesgos a lo largo de
múltiples squads.

Buenas Señales Señales de Mejora

- El IM del squad - El IM del equipo

participa en la nunca habla con
coordinación entre otro IM.
equipos/squads - No existe una
donde las coordinación entre
dependencias son múltiples equipos.
identificadas y
gestionadas.

ㅡ
Un desafío con los equipos interfuncionales es que las
6.3 Guilds
especialidades de una práctica (por ejemplo UX) tengan
un medio de apoyo. Promovemos Guilds para abordar el
aprendizaje y mejoras.

Buenas Señales Señales de Mejora

- La mayoría de los - Ningún miembro

miembros del squad del equipo participa
son parte al menos de un Guild.
de un Guild. - Los equipos no
- Los squads aprenden de otros y
aprenden de otros caen en los mismos
en diferentes niveles problemas.
y especialidades de
una prácticas.

25
ㅡ
6.4 Cumplimiento de Como equipo/squad, día a día estamos cumpliendo una
Regulaciones serie de obligaciones. Asimismo, dentro de la
organización, como un todo, existen regulaciones que
van más allá de los equipos/squads, incluyendo
algunas de entidades que son externas a la compañía.
A nivel de compañía, existe un marco regulatorio
interno, que podemos conocer con la ayuda de un
equipo especializado (Compliance).

Buenas Señales Señales de Mejora

- Conocemos al - Como equipo no

equipo conocemos el
especializado, nos marco regulatorio
hemos contactado interno.
con ellos y tenemos
claridad de las - Como equipo
cosas que debemos hemos escuchado
mejorar y comenzar del marco
a hacer. regulatorio interno,
pero no conocemos
- Conocemos al al equipo
equipo especializado en
especializado, nos ello.
hemos contactado
con ellos, trabajado - Si bien sabemos
conjuntamente en quiénes forman el
varios temas y equipo
actualmente no especializado, nunca
poseemos temas los hemos
pendientes a contactado y no lo
mejorar o a creemos necesario..
desarrollar.

-Algunos de los SME

de Compliance
participan en
algunas instancias
de inception.

26
7
_
Outcome Sobre Output
Éxito y propósito están alineados al objetivo global de generar
experiencias memorables.

ㅡ
Creemos que el éxito del equipo puede ser medido por
7.1 Outcome del equipo
el outcome y no por el output. Así, cada equipo
identificará al menos un KPI objetivo a impactar (por
ejemplo: NPS/CSAT, Rev, Costo). Adicionalmente, los
equipos serán medidos con métricas de compromiso
para su producto (por ejemplo: penetración, cobertura,
frecuencia de uso, etc.).

Buenas Señales Señales de Mejora

- El éxito es medido - El equipo es

en base a outcomes. medido basado en
output.
- La satisfacción del
usuario es medida - Hay celebraciones
en el tiempo y se cuando aumenta el
crean iniciativas para número de puntos
mejorarla. entregados.

- Los miembros del

equipo se apresuran
al final de un sprint
para entregar más
puntos.

27
8
_
Innovación Incorporada
Experimentar y explorar nuevas formas de hacer las cosas, usar
diferentes tecnologías, no parar de innovar e innovar a medida
que avanzas.

ㅡ
Cada equipo debe reservar capacidad para explorar
8.1 Exploración
nuevas forma de hacer las cosas, arreglar deuda técnica
existente e innovar a medida que se avanza.

Buenas Señales Señales de Mejora

- Los miembros del - ¿Innovación?, ¿qué?

squad han reservado Eso es algo que
capacidad para hacen otros equipos,
innovar. no nosotros.

28
ㅡ
8.2 Descubrimiento Creemos que el descubrimiento de productos debe
Continuo realizarse continuamente, de modo que el squad esté
constantemente llenando y refrescando su "estante de
oportunidades".

Buenas Señales Señales de Mejora

- La investigación de - La investigación de
usuarios usuarios
cuantitativo/cualitativo cuantitativa/cualitativ
es hecha a nunca se ha hecho
constantemente. o fue solamente una
vez, para la Inception,

29
9
_
Claridad Estratégica y Alineamiento
Trabajar juntos para crear y hacer visible una declaración de
propósito que definirá por qué este grupo de personas está
trabajando en equipo.

ㅡ
9.1 Declaración de Propósito Crear una declaración de propósito para el equipo.
Creemos que un grupo de personas juntas con un
propósito común puede hacer cosas maravillosas.
Trabajar juntos para crear y hacer visible una
declaración de propósito que definirá por qué este
grupo de personas está trabajando en conjunto. ¿Qué
los conecta? ¿Por qué se levantan cada mañana y hacen
lo que están haciendo?

Buenas Señales Señales de Mejora

- Todos los miembros - No existe un propósito

del squad comparten común u objetivo para
un propósito común los miembros del
para trabajar juntos. equipo.

- El propósito ha sido - Los miembros del

creado por el squad y equipo no están
es visible. comprometidos en un
propósito único.
- El propósito está
basado en outcome - No hay motivación de
los miembros del equipo
para trabajar en este
equipo.

- El propósito está
basado en output.

30
ㅡ
9.2Trade-off Sliders Trade-off es un acuerdo en el cual se deja algo fuera
para priorizar otra cosa que se desea más. Un producto
Lean refleja decisiones de un equipo en relación a los
trade-offs.
La actividad *Entendiendo los trade-offs* ayuda a
construir y documentar un entendimiento común acerca
de los acuerdos de un producto lean. Muchas
decisiones y conversaciones son basadas en visiones
individuales y premisas entre alternativas. Por ejemplo:
¿qué es más valioso? ¿la seguridad o la usabilidad? ¿y
entre desempeño y seguridad? ¿o usabilidad y
desempeño? Esta actividad promueve a una
conversación abierta y colaborativa sobre los trade-offs.
Los acuerdos claros evitan malos entendidos y ayudan a
tomar decisiones rápidamente.
Cuando hablamos de "sliders" pensemos en esos
controles deslizantes que usan los DJs en las consolas
de audio. Por ejemplo, podemos dibujar una línea
horizontal que tenga "Seguridad" en un extremo y
"Usabilidad" en el otro y marcar sobre esa línea en qué
punto nos queremos ubicar como equipo. ¿Más cerca
de "Seguridad" o de "Usabilidad"? ¿En un extremo o más
hacia el centro?
Las decisiones deben ser hechas basándose en trade-
off slider bien claros.

Buenas Señales Señales de Mejora

- Existe claridad en - No hay trade-off

las prioridades de sliders
las decisiones;
tenemos trade-off - Las decisiones son
sliders. tomadas de manera
inconsistente, de vez
-EJemplo concreto en cuando, y no
producto entendemos las
(comunicación) razones y
prioridades detrás
de ellas.

31
10
_
Búsqueda de la Excelencia Técnica
Usar, aprender e innovar prácticas que han sido consolidadas
en el mercado digital para entregar, continuamente, con
calidad y valor

ㅡ
La integración continua (CI) es una práctica de
10.1 Integración Continua desarrollo que requiere que los desarrolladores
integren código en un repositorio compartido varias
veces al día. Cada check-in es verificado por una
construcción automatizada, lo que permite a los
equipos/squads detectar problemas de forma
temprana y localizarlos más fácilmente.

Buenas Señales Señales de Mejora

- El equipo/squad - El pipeline
ha construido un permanece roto por
pipeline. largos periodos de
tiempo.
- Cada commit corre
todo el conjunto de - El equipo no posee
pruebas. autonomía para
mantener su pipeline.
- Cada commit
gatilla una nueva - El pipeline toma
construcción (build) mucho tiempo en
al ambiente de QA. ejecutarse.

- Ramas de larga vida

fuera de la rama base
(master o trunk).

- Nuevo código toma

más de 1 mes en ser
desplegado en
producción.

32
ㅡ
Cada nueva pieza de trabajo debe garantizar que los
10.2 Build Quality In estándares de calidad se cumplen y, además, que
mejora la situación actual. La calidad es parte del día a
día del equipo y es una responsabilidad compartida.

Contenido de Aprendizaje:
● http://www.101ways.com/lean-principles-2-
build-quality-in/

Buenas Señales Señales de Mejora

- El squad define su - Las pruebas son

propia estrategia de pobres y se rompen
prueba. de maneras
indeterminista.
- Existen diferentes
niveles de prueba, - La ejecución de las
con diferentes pruebas no es
propósitos. autónoma.

- Hay un nivel de - Hay pruebas de

prueba en el que se unidad sin
validan todos los aislamiento
componentes de la adecuado, existe
aplicación. superposición de
otras pruebas.
- Se aplican normas
de calidad del - Después de la
código de ejecución de un
producción para el pipeline, se
código de prueba. requieren pruebas
manuales.
- Es fácil evaluar el
impacto de los
cambios de código.

33
ㅡ
Entrega Continua es una disciplina de desarrollo de
10.3 Entrega Continua / software donde se construye de tal forma que el
DevOps
software puede ser lanzado a producción en cualquier
momento.

DevOps (palabra compuesta a partir “development” y

“operations”) es un proceso de desarrollo y entrega de
software que enfatiza la comunicación y la colaboración
entre la gestión de productos, el desarrollo , los
profesionales de operaciones y la estrecha alineación
con los objetivos de negocio. Proporciona valor
constantemente en producción.

Contenido de Aprendizaje:
● https://en.wikipedia.org/wiki/DevOps
● https://martinfowler.com/bliki/ContinuousDeliv
ery.html

Buenas Señales Señales de Mejora

- El squad tiene claridad - El proceso de

sobre el camino a despliegue en
producción y el control producción tarda
del proceso. demasiado en
ejecutarse.
- El squad va a producción
incluso antes de la - El despliegue en
primera función, con un producción a veces
"Hello World". requiere intervención
manual.
- El squad asegura que un
despliegue a producción - El despliegue en
no rompe nada. producción está
bloqueado por otras
- Es posible hacer un características.
despliegue en producción
en un momento dado. - Hay lanzamientos "big-
bang" en producción.
- El squad tiene un
mecanismo de despliegue - Necesidad de acceder
en producción manualmente a los
regularmente. servidores para
solucionar problemas.
- Capacidad para crear
fácilmente nuevos
entornos desde cero.

34
ㅡ
Creemos en usar el término Despliegue cuando se
10.4 Desacoplar Despliegue refiere al acto de desplegar un cambio en los
de Release
componentes de la aplicación o en la infraestructura. El
término Release debe utilizarse cuando un cambio de
características se libera a los usuarios finales, con un
impacto en el negocio. Usando técnicas tales como
“feature toggles” y lanzamientos oscuros (dark
launches), podemos desplegar cambios en los sistemas
de producción más frecuentemente sin liberar
funciones. Los despliegues más frecuentes reducen el
riesgo asociado con el cambio, mientras que los
stakeholders mantienen el control cuándo las
características se liberan a los usuarios finales.

Contenidos de Aprendizaje:
● Decoupling deployment from release

Buenas Señales Señales de Majora

- El PO es - Cuando se toma
responsable de los una decisión de
lanzamientos en negocio, es difícil
producción. liberar una función
ya implementada.
- El PO puede
activar una función, - La responsabilidad
tal vez con ayuda de una nueva
del squad, sin un versión de
despliegue en producción
producción. depende
enteramente de las
- El desarrollo de restricciones
nuevas técnicas.
características no se
lanza
inmediatamente
después de la
implementación.

35
ㅡ
Una creencia común sobre el software sostiene que los
10.5 Arquitectura Evolutiva elementos arquitectónicos son "difíciles de cambiar más
tarde". Las arquitecturas evolutivas, como primer
principio, diseñan para el cambio incremental. Son
atractivas porque el cambio ha sido históricamente
difícil de anticipar y costoso de reacomodar, pero si está
integrado en la arquitectura, es más fácil y más barato
de hacer, permitiendo cambios en las prácticas de
desarrollo, de release y en la agilidad en general.

Contenidos de Aprendizaje:
● Evolutionary Architectures
● Neal Ford on evolutionary architecture

Buenas Señales Señales de Mejora

- Lo que se - Diseño anticipado.

desarrolla es el
mínimo requerido - Los cambios de
para una código son
característica complejos y
determinada. retrasados.

- La refactorización - Sólo unos pocos

de la arquitectura es miembros del
frecuente. equipo son capaces
de explicar la visión
- Los requisitos técnica.
funcionales
cruzados son
constantemente re-
evaluados.

- Las decisiones
importantes sobre la
arquitectura están
documentadas y
alineadas con el
squad.

36
ㅡ
10.6 Seguridad en nuestro La seguridad es más allá de una tarea, ya que es parte
ADN del equipo/squad en todo momento. La seguridad no
es algo que los equipos /squads hacen porque son
buenos, sino que está presente por defecto en ellos.

Buenas Señales Señales de Mejora

- El squad se ha - El equipo no conoce

comunicado con el área los lineamientos de
de seguridad de la seguridad de la
organización para compañía.
conocer y entender los
lineamientos correctos. - El equipo no ha
hecho esfuerzos o no
- El squad ha ha conseguido
implementado y automatizar la
automatizado la seguridad dentro de su
seguridad dentro de su proyecto.
proyecto.
- El equipo no
- El squad monitorea posibles
constantemente ataques.
monitorea y busca
potenciales ataques. - El equipo no utiliza
herramientas para el
- El squad utiliza testeo de la seguridad
herramientas de code de sus aplicaciones.
review y “white box”, así
como algunas - Los pipelines del
herramientas y prácticas equipo no están sanos
“black box” para el y/o visibles.
testing de seguridad.
- No existe un Guild de
- El squad posee seguridad para velar
pipelines de ejecución por el cumplimiento de
sanos, visibles y únicos los lineamientos de la
por cada squad. compañía y entre
equipos.
- Hay miembros del
squad que participan - Existe un guild de
constantemente de temas de seguridad,
Guilds de Seguridad pero el equipo no
para estar siempre participa de ella.
alineados, mejorando
constantemente las
prácticas y velando por
el cumplimiento de ellas
al interior del squad.

37
11
_
Medir las cosas correctas
Medir y monitorear la satisfacción del usuario en el tiempo a lo
largo de la adopción digital, uso y tiempo de entrega de las
ideas.

ㅡ
11.1 Satisfacción del Nivel de satisfacción de los stakeholders del negocio en
Negocio términos del equipo y otros outcomes.

Buenas Señales Señales de Mejora

- Los stakeholders - Los stakeholders

del negocio están del negocio no
satisfechos con el están satisfechos
squad. con el equipo.

38
ㅡ
11.2 Output del Creemos que analizar las métricas de output de un
equipo/ squad equipo (por ejemplo, tendencia de la velocidad,
efectividad de la entrega, deuda técnica, lead
time/cycle time, cobertura de pruebas, errores en pre-
prod y prod, etc.), puede ser valioso como indicador y
brindarnos información para optimizar el CÓMO
entregamos. Es responsabilidad del IM el monitorear
aquello consistentemente y facilitar discusiones con el
equipo/squad de proyecto.

Buenas Señales Señales de Mejora

- Tenemos al menos - No estamos

una métrica de midiendo métricas
output - ¿Cuál? Por de output, sólo nos
favor explique. dedicamos a
entregar.
- La métrica de
output no es la - La métrica de
medida más output es la medida
importante de éxito. más importante de
éxito.

39
ㅡ
Métricas de uso para las características entregadas. El
11.3 Uso equipo necesita maximizar el número de características
entregadas que se usan y minimizar, e incluso
deshacerse, de las características que nunca se usarán.

Buenas Señales Señales de Mejora

- El squad ejecuta - El uso de las

pruebas A/B y sólo características es
mantiene las bajo.
características que
son altamente
utilizadas. - No medimos el
uso,Los usuarios no
usan lo que se les
- El uso de entrega.
características
aumenta con el
tiempo.

- Más usuarios usan

más características
entregadas.

- El equipo está
analizando data para
validar el diseño y
futuras
oportunidades sin
improvisaciones en
el producto.

40
ㅡ
11.4 Adopción Digital Se entregan productos digitales para resolver
necesidades del usuario, algunas de las cuales se
resolvían por canales no digitales. Es importante medir
la migración desde lo no digital a lo digital.

Buenas Señales Señales de Mejora

- Las necesidades - No existe

del usuario que migración de
fueron resueltas en usuarios de canales
canales no digitales no digitales a
ahora son resueltas canales digitales
por canales que sí lo entregados por este
son, a través de equipo.
características que
entregó el squad.

- El equipo está
continuamente
revisando
oportunidades para
pasar de cosas no
digitales a digitales

ㅡ
11.5 Tiempo de Entrega El tiempo que transcurre desde que una idea aparece
en la mente de alguien hasta que se implementa en
producción, es medido y mejorado continuamente.

Buenas Señales Señales de Mejora

- El tiempo de - ¿Tiempo de
entrega es medido y entrega? ¿Qué es
mejorado en el eso?
tiempo.

41
ㅡ
11.6 Satisfacción del Usuario Medir el nivel de satisfacción de los usuarios en
términos del equipo y de cómo sus necesidades son
resueltas a través de los productos digitales y las
características entregadas.

Buenas Señales Señales de Mejora

- La satisfacción del - La satisfacción de

usuario es medida y usuario no es
mejorada en el medida.
tiempo.
- La satisfacción de
-Saber distinguir usuario es baja y
cuál métrica nunca mejora.
impactar fuera de
los king KPI’s para
evaluar

42