Suscríbete a DeepL Pro para poder editar este documento.

Entra en www.DeepL.com/pro para más información.

 Tabla de Contenidos
Acerca de este eBook
Página de título
Página de derechos de autor
Página de dedicación
Contenido
Prólogo de David J. Anderson
Prólogo de Jim Benson
Prefacio
Cómo usar este libro
Cómo está organizado este libro
Convenciones
Agradecimientos
Sobre el autor
Parte I: Introducción
Capítulo 1. Manifestaciones: Scrumban desmitificada
Una perspectiva útil
Un marco para la[R]Evolución
Deje de beber el Kool-Aid
Vamos a empezar
Parte II: Fundamentos - Empezar con el fin en mente
Capítulo 2. La Matriz y el Desorden: Donde Todo Comienza
Parte 1: La Matriz (Los Orígenes de Scrumban)
Qué es y qué no es Scrumban
Gestión del trabajo de conocimiento
Comience el viaje con el pensamiento sistémico
Scrumban puede incorporar otros modelos y marcos
Por qué es relevante el pensamiento sistémico
Sistemas en nuestros entornos de trabajo
El enfoque de Scrumban para entender los sistemas
Parte 2: El lío (Razones por las que se necesita Scrumban)
Por qué queremos ser"ágiles".
Por qué las adopciones ágiles se estancan o fracasan
Atando todo junto
Capítulo 3. La Misión: Aclarar la relación entre el propósito, los valores y el
rendimiento
Por qué nos pagan por trabajar
La importancia del propósito compartido
La importancia de las capacidades de adaptación
Comunicación y aplicación de los valores fundamentales en la toma
de decisiones
 Ser Disciplinado sobre las Métricas Correctas
Usando Enfoques Disciplinados para Identificar y Abordar los
Problemas Más Importantes
Atando todo junto
Capítulo 4. Motivaciones: Por qué funciona Scrumban
Donde Todo Comenzó
Estratificación del método Kanban
Atención a la Agenda Psicológica
Agendas del Método Kanban
Principios y Prácticas Básicos del Método Kanban
La Lente Kanban
Kanban Kata y Prácticas Relacionadas
La importancia de los valores complementarios
Scrum
Kanban
Scrumban
La relación de Scrumban con el pensamiento ágil
Otros marcos y modelos
A3 Pensamiento
El marco Cynefin
Opciones reales
Algunas reflexiones finales sobre el pensamiento sistémico
Atando todo junto
Parte III: Ejecución - Poner en práctica el Scrumban
Capítulo 5. Movilízate: Despliegue de Scrumban
Su condición inicial
Cuando usted es nuevo en Scrum
El proceso Kickstart
Preparación
Consideraciones iniciales
La forma en que usted elige organizar hace la diferencia
Responsabilidades contextuales
El Evento Kickstart
Observaciones introductorias
Preocupaciones actuales
Definición del propósito y los criterios de éxito
Identificar cómo se realiza el trabajo
Enfocarse en los tipos de trabajo
Gestión Básica
Idioma común (Opcional)
Políticas de visualización
Frecuencia de sincronización
 Crear un tablero de trabajo
Políticas de la forma de trabajar
Limitación del WIP
Planificación y ciclos de retroalimentación
Flujo individual (opcional)
Conclusión de la reunión
Algunas reflexiones finales
Atando todo junto
Capítulo 6. Método: Trabajando bajo la capucha
Gestión de la incertidumbre y el riesgo
Tipos de incertidumbre y riesgo
Cómo Scrumban mejora la gestión del riesgo
Flujo mejorado a través de los límites y búferes de WIP
Visualización del riesgo
Cuantificación del coste o del valor
Costo de la demora en el empleo
Uso de clases de servicio
Continuar enfatizando el desglose adecuado del trabajo
Facilitar las transiciones con funciones en evolución
Liberaciones y sprints
Pensando de manera diferente sobre el compromiso
Flujo Continuo versus Iteraciones en Caja de Tiempo
Dimensiones adicionales para la gestión de los lanzamientos y
esprints
Mejora de la planificación y la previsión
Planificación Temprana
Muestreo aleatorio por lotes
Planeando con Little's Law
Ejemplo de planificación de proyecto/liberación
Espera un minuto: Contabilidad de la incertidumbre inherente
El búfer de proyectos como herramienta de gestión
Gestión Adaptativa de Buffer
Un enfoque más disciplinado para la planificación de Sprint
Lazos de retroalimentación
Mecanismos de retroalimentación: Scrum versus Kanban versus
Scrumban
Peligros potenciales de los circuitos de retroalimentación
Pensamiento de diseño
Diseño de Tickets
Diseño de Tableros
Atando todo junto
Capítulo 7. Medidas: Obtención de información y seguimiento del progreso
¿Por qué medir?
 Unas pocas palabras sobre la medición de las cosas incorrectas
Los sellos de las buenas métricas
Cómo medir
Construyendo histogramas
Medidas de Scrumban
Métricas de productividad
Diagrama de flujo acumulativo
Superposición CFD/Burn-up
Plazo de entrega
Rendimiento
Envejecimiento del WIP
Eficiencia del flujo
Cadencia
Métricas de calidad
Demanda de fallas
Impacto de los bloqueadores
Desempeño en la Fecha de Vencimiento
Distribución de Tarifas de Llegada y Distribución de Tarifas de
Servicio
Métricas de riesgo
Gráfico de quemado mejorado
Gráfico de reducción de riesgos
Gráfico de índice de riesgo
Mejora de las métricas de riesgo
Extendiendo Scrumban más allá de TI: El Balanced Scorecard
Encontrar las medidas adecuadas
Medición de lo que importa
Objetivos estratégicos en cascada
Atando todo junto
Parte IV: Mejorando Temas y Prácticas Avanzadas
Capítulo 8. Gestión: La gerencia está haciendo las cosas bien - El liderazgo está
haciendo las cosas bien
Liderazgo Conviccional
Liderazgo de servicio
Los buenos líderes reconocen que el trabajo de conocimiento es diferente
Combatiendo la entropía
Nutrir y proteger los valores fundamentales
Establecimiento del uso adecuado de las métricas
Mejorar el liderazgo a través de una mejor comunicación
Poniendo todo junto
Reforzando el liderazgo a través de la gestión
Fomentar los sistemas de pensamiento y el empuje contra el tirón
Alentando el Liderazgo de Servicio
 Gestión Adaptativa de Riesgos y Toma de Decisiones Locales
Facilitar la evolución de los roles
Gerente de Producto
Analista de negocios
Gestor de proyectos/Maestro de scrum
Aseguramiento de la calidad
Atando todo junto
Capítulo 9. Madurando: Como un buen vino, Scrumban puede mejorar con la
edad
Priorización y gestión del cambio
Gestión del vencimiento
Niveles de vuelo
Medición de la profundidad de las capacidades
Otro enfoque
Evolución de sus capacidades básicas
Gestionar el flujo
Límite WIP
Gestione los cuellos de botella y mejore el flujo
Evite patrones de cambios inseguros
Crear un Enfoque Disciplinado para el Mejoramiento
Los katas y la importancia del hábito
Evolución ulterior de la comprensión y la gestión del riesgo
Estrategias de manejo de riesgos
Ejemplos de prácticas de maduración
Expansión de sus horizontes de gestión de riesgos
Escalar más allá de la TI
Más allá del presupuesto (Agile Budgeting)
Contratación Ágil
La larga cola de la rentabilidad
Atando todo junto
Capítulo 10. Modelado: Para ir audazmente a donde pocos han ido antes
¿Por qué modelar?
Comenzando con Métricas y Patrones de Distribución
Por qué los patrones son relevantes
¿Qué es el modelado?
Recordatorio sobre el "Defecto de los promedios"
Consideraciones iniciales
Simulaciones Monte Carlo
Construyendo sobre lo que ya hace
Todavía no es perfecto
Consideración de los principales factores de riesgo
Un enfoque diferente
 Parámetros de entrada: El bamboleo de Weibull, pero no se
derrumban
Cómo crear un modelo robusto
Un experimento de muestra de "Qué pasaría si
Bootstrapping
Algunas Palabras Finales
Apéndice. Más: Por la fortaleza del corazón
Scrum in a Nutshell
El proceso de trabajo de Scrum
Roles de Scrum
Planificación de póquer
Scrum y Scrumban: Algunas comparaciones rápidas
Mapa de Scrumban: Una referencia rápida para empezar
Paso 1: Visualice su sistema
Paso 2: Comience a medir el desempeño
Paso 3: Estabilice su sistema y mejore el enfoque con límites de WIP
Paso 4: Mejore su comprensión y gestión del riesgo
Paso 5: Mejorar continuamente
Uso de Scrumban para introducir Scrumban
Paso 1: Proporcione el contexto
Paso 2: Introducir elementos Scrum en respuesta a los descubrimientos
del equipo
Paso 3: Maduración
Scrumban y SAFe
Historias de Scrumban: Los estudios de caso completos
Historia de Scrumban 1: Banco Mammoth (Parte 1)
Historia de Scrumban 2: Banco Mammoth (Parte 2)
Scrumban Story 3: Siemens Health Care
3. Scrumban Story 4: Soluciones objetivas
Información y recursos suplementarios
Facilitando Conversaciones Difíciles
Una perspectiva adicional sobre la gestión eficaz de los productos
Marco Cynefin
Opciones reales
El juego GetScrumban
Herramientas Scrumban: Ejemplos de características y capacidades clave
Ejemplos de Tableros
Indice
Acerca de este eBook

ePUB es un formato abierto y estándar de la industria para libros electrónicos.

Sin embargo, el soporte de ePUB y sus numerosas funciones varía según los
dispositivos de lectura y las aplicaciones. Utilice la configuración de su dispositivo
o aplicación para personalizar la presentación a su gusto. Los ajustes que puede
personalizar a menudo incluyen fuente, tamaño de fuente, columnas simples o
dobles, modo apaisado o vertical, y figuras que puede hacer clic o tocar para
ampliar. Para obtener información adicional sobre la configuración y las funciones
de su dispositivo de lectura o aplicación, visite el sitio web del fabricante del
dispositivo.
Muchos títulos incluyen código de programación o ejemplos de configuración.
Para optimizar la presentación de estos elementos, vea el eBook en modo
horizontal de una sola columna y ajuste el tamaño de la fuente a la configuración
más pequeña. Además de presentar el código y las configuraciones en el formato
de texto refluible, hemos incluido imágenes del código que imitan la presentación
encontrada en el libro impreso; por lo tanto, cuando el formato refluible pueda
comprometer la presentación de la lista de códigos, verá un enlace "Haga clic aquí
para ver la imagen del código". Haga clic en el enlace para ver la imagen del código
de fidelidad de impresión. Para volver a la página anterior, haga clic en el botón
Atrás de su dispositivo o aplicación.
 La
[R]Evolución Scrumban
Aprovechar al máximo el uso de Agile, Scrum
y Lean Kanban

Ajay Reddy

Nueva York - Boston - Indianápolis - San FranciscoToronto

- Montreal - Londres - Munich - París - MadridCapetown
- Sydney - Tokio - Singapur - Ciudad de México
Muchas de las denominaciones utilizadas por fabricantes y vendedores para
distinguir sus productos se reivindican como marcas comerciales. Cuando esas
designaciones aparecen en este libro, y el editor tenía conocimiento de una
reivindicación de marca, las designaciones se han impreso con letras mayúsculas
iniciales o en todas las mayúsculas.
El autor y el editor han tenido cuidado en la preparación de este libro, pero no dan
ninguna garantía expresa o implícita de ningún tipo y no asumen ninguna
responsabilidad por errores u omisiones. No se asume ninguna responsabilidad
por daños incidentales o consecuentes en relación con o que surjan del uso de la
información o de los programas aquí contenidos.
Para obtener información sobre la compra de este título en grandes cantidades, o
para oportunidades de ventas especiales (que pueden incluir versiones
electrónicas, diseños de portadas personalizadas y contenido específico de su
negocio, objetivos de formación, enfoque de marketing o intereses de marca),
póngase en contacto con nuestro departamento de ventas corporativas en
corpsales@pearsoned.com o en el (800) 382-3419.
Para consultas sobre ventas del gobierno, póngase en contacto con
governmentsales@pearsoned.com.
Para preguntas sobre ventas fuera de los EE.UU., por favor contacte a
international@pearsoned.com.
Visítenos en la Web: informit.com/aw
Biblioteca del Congreso Datos de catalogación de publicaciones
Reddy, Ajay.
La[r]evolución de Scrumban: sacar el máximo provecho de Agile, Scrum, y Kanban
/ Ajay Reddy magra
.
ISBN 978-0-13-408621-7 (pbk. : papel alcalino)-ISBN 0-13-408621-X (pbk. : papel
alcalino)
. Gestión de proyectos - Procesamiento de datos. 2. Fabricación ajustada. 3.
Desarrollo ágil de software.
4. Scrum (Desarrollo de software informático) I. Título. II. Título: Evolución
Scrumban. III. Título:
revolución scrumban.
T56.8.R43 2016
005.1068'4-dc23
Derechos de autor © 2016 Pearson Education, Inc.
Todos los derechos reservados. Impreso en los Estados Unidos de América. Esta
publicación está protegida por derechos de autor, y se debe obtener permiso del
editor antes de cualquier reproducción prohibida, almacenamiento en un sistema
de recuperación, o transmisión en cualquier forma o por cualquier medio,
electrónico, mecánico, fotocopiado, grabación, o de la misma manera. Para obtener
permiso para usar el material de este trabajo, por favor envíe una solicitud por
escrito a Pearson Education, Inc. al Departamento de Permisos, 200 Old Tappan
Road, Old Tappan, New Jersey 07657, o puede enviar su solicitud por fax al (201)
236-3290.
ISBN-13: 978-0-13-408621-7ISBN-10
: 0-13-408621-X
Texto impreso en los Estados Unidos en papel reciclado en RR Donnelley en
Crawfordsville, Indiana.
Primera impresión, julio de 2015
Dedico este trabajo a mi primogénito, Nehemías Subhinay, llamado así por
Nehemías 400-450 a.C., quien dirigió el primer proyecto ágil de la
historia, completando el muro alrededor de Jerusalén en 52 días.
Contenido

Prólogo de David J. Anderson

Prólogo de Jim Benson

Prefacio

Agradecimientos

Sobre el autor

Parte I Introducción

Capítulo 1 Manifestaciones: Scrumban desmitificada

Una perspectiva útil
Un marco para la[R]Evolución
Deje de beber el Kool-Aid
Vamos a empezar

Fundamentos de la Parte II - Empezar con el fin en mente

Capítulo 2 La Matriz y el Desorden Donde Todo Comienza

Parte 1: La Matriz (Los Orígenes de Scrumban)
Qué es y qué no es Scrumban
Gestión del trabajo de conocimiento
Comience el viaje con el pensamiento sistémico
Scrumban puede incorporar otros modelos y marcos
Por qué es relevante el pensamiento sistémico
Sistemas en nuestros entornos de trabajo
El enfoque de Scrumban para entender los sistemas
Parte 2: El lío (Razones por las que se necesita Scrumban)
Por qué queremos ser"ágiles".
Por qué las adopciones ágiles se estancan o fracasan
Atando todo junto

Capítulo 3 La Misión: Aclarar la relación entre el propósito, los valores y el

rendimiento
Por qué nos pagan por trabajar
La importancia del propósito compartido
La importancia de las capacidades de adaptación
Comunicación y aplicación de los valores fundamentales en la toma de
decisiones
 Ser Disciplinado sobre las Métricas Correctas
Usando Enfoques Disciplinados para Identificar y Abordar los Problemas
Más Importantes
Atando todo junto

Capítulo 4 Motivaciones: Por qué funciona Scrumban

Donde Todo Comenzó
Estratificación del método Kanban
Atención a la Agenda Psicológica
Agendas del Método Kanban
Principios y Prácticas Básicos del Método Kanban
La Lente Kanban
Kanban Kata y Prácticas Relacionadas
La importancia de los valores complementarios
Scrum
Kanban
Scrumban
La relación de Scrumban con el pensamiento ágil
Otros marcos y modelos
A3 Pensamiento
El marco Cynefin
Opciones reales
Algunas reflexiones finales sobre el pensamiento sistémico
Atando todo junto

Ejecución de la Parte III - Poner en práctica el Scrumban

Capítulo 5 Movilícese: Despliegue de Scrumban

Su condición inicial
Cuando usted es nuevo en Scrum
El proceso Kickstart
Preparación
Consideraciones iniciales
La forma en que usted elige organizar hace la diferencia
Responsabilidades contextuales
El Evento Kickstart
Observaciones introductorias
Preocupaciones actuales
Definición del propósito y los criterios de éxito
 Identificar cómo se realiza el trabajo
Enfocarse en los tipos de trabajo
Gestión Básica
Idioma común (Opcional)
Políticas de visualización
Frecuencia de sincronización
Crear un tablero de trabajo
Políticas de la forma de trabajar
Limitación del WIP
Planificación y ciclos de retroalimentación
Flujo individual (opcional)
Conclusión de la reunión
Algunas reflexiones finales
Atando todo junto

Capítulo 6 Método: Trabajando bajo la capucha

Gestión de la incertidumbre y el riesgo
Tipos de incertidumbre y riesgo
Cómo Scrumban mejora la gestión del riesgo
Flujo mejorado a través de los límites y búferes de WIP
Visualización del riesgo
Cuantificación del coste o del valor
Costo de la demora en el empleo
Uso de clases de servicio
Continuar enfatizando el desglose adecuado del trabajo
Facilitar las transiciones con funciones en evolución
Liberaciones y sprints
Pensando de manera diferente sobre el compromiso
Flujo Continuo versus Iteraciones en Caja de Tiempo
Dimensiones adicionales para la gestión de los lanzamientos y esprints
Mejora de la planificación y la previsión
Planificación Temprana
Muestreo aleatorio por lotes
Planeando con Little's Law
Ejemplo de planificación de proyecto/liberación
Espera un minuto: Contabilidad de la incertidumbre inherente
El búfer de proyectos como herramienta de gestión
Gestión Adaptativa de Buffer
 Un enfoque más disciplinado para la planificación de Sprint
Lazos de retroalimentación
Mecanismos de retroalimentación: Scrum versus Kanban versus
Scrumban
Peligros potenciales de los circuitos de retroalimentación
Pensamiento de diseño
Diseño de Tickets
Diseño de Tableros
Atando todo junto

Capítulo 7 Medidas: Obtención de información y seguimiento del progreso

¿Por qué medir?
Unas pocas palabras sobre la medición de las cosas incorrectas
Los sellos de las buenas métricas
Cómo medir
Construyendo histogramas
Medidas de Scrumban
Métricas de productividad
Diagrama de flujo acumulativo
Superposición CFD/Burn-up
Plazo de entrega
Rendimiento
Envejecimiento del WIP
Eficiencia del flujo
Cadencia
Métricas de calidad
Demanda de fallas
Impacto de los bloqueadores
Desempeño en la Fecha de Vencimiento
Distribución de Tarifas de Llegada y Distribución de Tarifas de Servicio
Métricas de riesgo
Gráfico de quemado mejorado
Gráfico de reducción de riesgos
Gráfico de índice de riesgo
Mejora de las métricas de riesgo
Extendiendo Scrumban más allá de TI: El Balanced Scorecard
Encontrar las medidas adecuadas
Medición de lo que importa
 Objetivos estratégicos en cascada
Atando todo junto

Parte IV Mejorando Temas y Prácticas Avanzadas

Capítulo 8 Gestión: La gerencia está haciendo las cosas bien - El liderazgo está
haciendo las cosas bien
Liderazgo Conviccional
Liderazgo de servicio
Los buenos líderes reconocen que el trabajo de conocimiento es diferente
Combatiendo la entropía
Nutrir y proteger los valores fundamentales
Establecimiento del uso adecuado de las métricas
Mejorar el liderazgo a través de una mejor comunicación
Poniendo todo junto
Reforzando el liderazgo a través de la gestión
Fomentar los sistemas de pensamiento y el empuje contra el tirón
Alentando el Liderazgo de Servicio
Gestión Adaptativa de Riesgos y Toma de Decisiones Locales
Facilitar la evolución de los roles
Gerente de Producto
Analista de negocios
Gestor de proyectos/Maestro de scrum
Aseguramiento de la calidad
Atando todo junto

Capítulo 9 Maduración: Como un buen vino, Scrumban puede mejorar con la

edad
Priorización y gestión del cambio
Gestión del vencimiento
Niveles de vuelo
Medición de la profundidad de las capacidades
Otro enfoque
Evolución de sus capacidades básicas
Gestionar el flujo
Límite WIP
Gestione los cuellos de botella y mejore el flujo
Evite patrones de cambios inseguros
Crear un Enfoque Disciplinado para el Mejoramiento
Los katas y la importancia del hábito
 Evolución ulterior de la comprensión y la gestión del riesgo
Estrategias de manejo de riesgos
Ejemplos de prácticas de maduración
Expansión de sus horizontes de gestión de riesgos
Escalar más allá de la TI
Más allá del presupuesto (Agile Budgeting)
Contratación Ágil
Más sobre la larga cola de la rentabilidad
Atando todo junto

Capítulo 10 Modelado: Para ir audazmente a donde pocos han ido antes

¿Por qué modelar?
Comenzando con Métricas y Patrones de Distribución
Por qué los patrones son relevantes
¿Qué es el modelado?
Recordatorio sobre el "Defecto de los promedios"
Consideraciones iniciales
Simulaciones Monte Carlo
Construyendo sobre lo que ya hace
Todavía no es perfecto
Consideración de los principales factores de riesgo
Un enfoque diferente
Parámetros de entrada: El bamboleo de Weibull, pero no se derrumban
Cómo crear un modelo robusto
Un experimento de muestra de "Qué pasaría si
Bootstrapping
Algunas Palabras Finales

Apéndice Más: Por la fortaleza del corazón

Scrum in a Nutshell
El proceso de trabajo de Scrum
Roles de Scrum
Planificación de póquer
Scrum y Scrumban: Algunas comparaciones rápidas
Mapa de Scrumban: Una referencia rápida para empezar
Paso 1: Visualice su sistema
Paso 2: Comience a medir el desempeño
Paso 3: Estabilice su sistema y mejore el enfoque con límites de WIP
 Paso 4: Mejore su comprensión y gestión del riesgo
Paso 5: Mejorar continuamente
Uso de Scrumban para introducir Scrumban
Paso 1: Proporcione el contexto
Paso 2: Introducir elementos Scrum en respuesta a los descubrimientos
del equipo
Paso 3: Maduración
Scrumban y SAFe
Historias de Scrumban: Los estudios de caso completos
Historia de Scrumban 1: Banco Mammoth (Parte 1)
Historia de Scrumban 2: Banco Mammoth (Parte 2)
Scrumban Story 3: Siemens Health Care
3. Scrumban Story 4: Soluciones objetivas
Información y recursos suplementarios
Facilitando Conversaciones Difíciles
Una perspectiva adicional sobre la gestión eficaz de los productos
Marco Cynefin
Opciones reales
El juego GetScrumban
Herramientas Scrumban: Ejemplos de características y capacidades clave
Ejemplos de Tableros

Indice
Prólogo de David J. Anderson

"Scrum es duro", dice Ken Schwaber, uno de los creadores del método. Es un
proceso definido con un conjunto de reglas prescriptivas que se sabe que
funcionan en combinación. Se sabe que Scrum funciona en el contexto para el que
fue diseñado. El verdadero desafío para aquellos que adoptan Scrum es cambiar su
contexto para permitir que Scrum sea efectivo para ellos. Cambiar el contexto de
su negocio y las demandas de sus clientes no es fácil y, por lo tanto, "Scrum es
difícil".
En 2002, cuando estaba contemplando por primera vez lo que ahora conocemos
como el Método Kanban, Scrum no era el método ágil dominante que es hoy en día.
Agile era nuevo y el término "desarrollo de software ágil" existía desde hacía sólo
un año. El más conocido de los métodos ágiles fue la Programación Extrema.
Muchas organizaciones de desarrollo de software seguían practicando los métodos
desarrollados en las décadas de 1980 y 1990 y utilizando técnicas como los casos
de uso para capturar los requisitos. La planificación de los proyectos se hacía con
diagramas de Gantt, y los procesos de gobernanza en fase que obligaban a
proyectos enteros a gran escala conocidos como "fases" eran comunes. Habría una
fase de recopilación de requisitos, una fase de análisis de sistemas, una fase de
diseño, etc. Los métodos ágiles, con sus pequeños incrementos de entrega y
enfoques iterativos de codificación y pruebas, daban miedo y su adopción era
lenta. Donde vi la mayor resistencia fue en la adopción de enfoques más flexibles
para la definición de los requisitos, como el uso de historias de usuarios, y en el
desmantelamiento de los procesos de gobernanza de la fase inicial, a menudo
controlados por las oficinas de gestión de programas o carteras, o en una función
de auditoría o calidad que a menudo informa a la PMO.
Llegué a la conclusión de que si queríamos ofrecer una verdadera agilidad
empresarial a las masas de empresas de desarrollo tecnológico de todo el mundo,
teníamos que adoptar un nuevo enfoque de la mejora. En lugar de tratar de
reemplazar los métodos existentes con nuevos (pero atemorizantes) métodos
ágiles, deberíamos seguir un enfoque evolutivo en el que "comencemos con lo que
hacemos ahora" y busquemos problemas específicos que existen, y luego
busquemos formas específicas de solucionarlos.
En 2004, vi un patrón en el que los departamentos de TI y los grupos de
desarrollo de productos se comprometían a trabajar demasiado, demasiado
pronto; hacían planes basados a menudo en suposiciones idealistas; y luego no
cumplían sus promesas, lo que llevaba a clientes insatisfechos. Las causas de las
fallas formaron un patrón común. El trabajo comprometido cambiaría de alcance y
definición, mientras que llegarían nuevos trabajos, y el trabajo en curso se
interrumpiría a menudo por razones de recopilación de información, o para volver
a trabajar, o para solucionar problemas de producción. El trabajo comprometido
en curso se dejaría de lado y se bloquearía por muchas razones, y la planificación
de la gestión de riesgos había sido insuficiente para tener en cuenta estos
problemas. La solución para muchos de estos problemas fue adoptar un sistema de
kanban como primer paso en un proceso de mejora evolutiva. Los sistemas Kanban
nos animan a diferir el compromiso, limitando el trabajo en curso y limitando
nuestra exposición a muchos de los problemas comunes que hacen que las
promesas se rompan y los proyectos no cumplan con las expectativas.
Estas dos cosas estaban separadas: Necesitábamos un enfoque evolutivo para
mejorar la prestación de servicios en el trabajo de TI y el desarrollo de productos,
y los sistemas kanban eran una buena solución para el compromiso inicial poco
realista y los problemas de interrupciones, cambios y crecimiento del alcance, y
bloqueo de trabajo por una multitud de razones. Resultó que el patrón que
requería el uso de un sistema Kanban era tan común que en 2007 los conceptos se
habían fusionado en un único enfoque de gestión que ahora conocemos como el
"Método Kanban".
Así que Kanban era"agilidad para el resto de nosotros". Kanban fue diseñado
para brindar agilidad a aquellos que no pudieron o no quisieron adoptar métodos
ágiles definidos en la década de 2000. ¿Qué tiene que ver esto con Scrum? Bueno,
Scrum es duro. Probablemente ha sido sobrevendido a un público deseoso de
encontrar una solución sencilla a sus retos de entrega. Muchas empresas han
adoptado Scrum sin cumplir con todos sus requisitos, no han cambiado su contexto
a uno que sea realmente adecuado para Scrum. De hecho, en muchos casos,
simplemente no es posible controlar el contexto de su negocio; en cambio, sus
clientes y su mercado lo hacen por usted. No cambian para adaptarse a la forma en
que usted desea trabajar, sino que usted debe cambiar para adaptarse a la forma
en que ellos esperan que usted haga negocios con ellos. Esto ha dejado un mundo
lleno de implementaciones de Scrum problemáticas, incompletas o deslucidas.
Resulta que a pesar de los incrementos más pequeños de sprints, muchas
implementaciones de Scrum sufren de las mismas dolencias que yo observé con los
métodos tradicionales de gestión de proyectos y desarrollo de software hace más
de una década. Por lo tanto, adoptar Kanban es una forma apropiada de ayudar a
una implementación de Scrum desafiante a evolucionar y ajustarse al contexto en
el que se está utilizando. Esto no hace felices a los puristas. No es "Scrum por el
conjunto definido de reglas", así que, según Ken Schwaber, no es Scrum. La
pregunta que usted debe hacerse es, "¿Es nuestra meta hacer Scrum perfectamente
y ser ciudadanos de primera clase en la comunidad mundial de Scrum? ¿O nuestro
objetivo es mejorar la prestación de servicios de TI, desarrollo de software y
nuevos productos a nuestros clientes?". Si usted reconoce esto último como su
verdadero objetivo, entonces tiene que aceptar que se requiere algún grado de
adaptación para desarrollar un proceso que sea único para su propia situación y
"apto para el propósito". El hecho de que haya tomado este libro y se haya tomado
la molestia de leer el prólogo sugeriría que ya reconoce que seguir estrictamente
las reglas de Scrum no está funcionando para usted, y que necesita ayuda para
evolucionar hacia algo que se ajuste mejor al contexto de su negocio.
Ajay Reddy es un experimentado practicante de Scrum que ha pasado por el
mismo viaje en el que usted se encuentra. Él también descubrió que necesitaba
ayuda, y descubrió que el mensaje del Método Kanban resonaba en su mente y le
permitía ofrecer soluciones a lo que parecía ser un problema difícil de resolver. Si
Scrum no ha estado trabajando para usted, tal vez el problema no radica en usted y
en su capacidad para seguir sus estrictas reglas correctamente. Tal vez la verdad es
que usted necesita una solución de proceso diferente, hecha a la medida de su
situación. Deja que Kanban te ayude a conseguirlo, y deja que Ajay te guíe en cómo
hacerlo.
Si hay un solo mensaje que quiero que le quites a este prólogo, está contenido
en esta cita de mi propio libro, Kanban: Exitoso cambio evolutivo para su negocio de
tecnología: "Tienes permiso para intentarlo con Kanban. Usted tiene permiso para
modificar su proceso. Tienes permiso para ser diferente. Su situación es única y
usted merece desarrollar una definición de proceso única, adaptada y optimizada a
su dominio, su flujo de valor, los riesgos que gestiona, las habilidades de su equipo
y las demandas de sus clientes". Esté orgulloso de lo que ha logrado hasta ahora
con Scrum y acepte la idea de que hay mucho más que puede hacer en el futuro.
Deja que Kanban te ayude a llegar allí.

-David J. AndersonSequim
, Washington
Prólogo de Jim Benson

Si hubiera un principio central de Lean, uno del que nadie habla nunca, sería
simplemente esto:

Tienes que prestar atención a tu proyecto.

Eso es simplemente todo. Para mejorar continuamente o para entregar un

producto de calidad, necesitamos saber realmente, como equipo, lo que estamos
haciendo y por qué.
Cuando abandonamos nuestros proyectos o nuestra comprensión de nuestros
clientes a técnicas de gestión prescriptivas, estamos diciendo que nosotros
(nuestro equipo y nuestro producto) somos sólo otra fábrica de software común y
corriente. Predecible, mecánico, inverosímil. Certificable.
Pero muy pocos proyectos pueden decir que han alcanzado este nivel de lo
mundano. La creación de software aumenta la rentabilidad sólo gracias a los
diferenciadores. Los diferenciadores requieren visión. La visión requiere
creatividad. Y la creatividad requiere experimentación e imaginación.
No somos robots. El software no es una línea de montaje, ni mucho menos. Por
lo tanto, los desarrolladores de software y los que se sienten atraídos por la
industria tienen algunas características comunes clave:
1. Resuelven problemas.
2. Son inventores.
3. Son artesanos.
4. Se enfadan mucho cuando se les niega la posibilidad de tener 1-3 años.
En 2008, cuando mi colega Corey Ladas escribió Scrumban: Ensayos sobre
Sistemas Kanban para el Desarrollo de Software Lean, él estaba extendiendo la
definición de técnicas ágiles cada vez más prescriptivas al proporcionar dos cosas
importantes:
Un conjunto de herramientas para prestar atención
Permiso para prestar atención
El desarrollo de software es un sistema que está creando otros sistemas. Es
intrincado. Es social. Es complejo. No tenemos estantes y estantes de libros sobre
cómo desarrollar software porque es fácil. Cada proyecto tiene muchos caminos
potenciales de implementación, muchos ciclos de vida potenciales y muchas
decisiones.
A su vez, cada sitio web, aplicación o programa integrado que creamos es en sí
mismo un sistema. Interactúa con el usuario, interactúa con otro software, se
rompe, necesita ser mantenido. Nuestros productos de software viven dentro de
mundos sociales, financieros y digitales que al menos debemos apreciar, si no
entender, para crear el código apropiado.
Así que honestamente debo pedirte a ti y a tu actual práctica ágil:
 ¿Está configurando sus equipos de desarrollo con un sistema que les permita
ver realmente el contexto en tiempo real de su trabajo?
¿Permite su sistema que su equipo se dé cuenta temprano cuando hay
problemas?
¿Les permite cambiar no sólo las características, sino también sus procesos?
¿Realmente les permite un ritmo sostenible (desarrollar un producto de
calidad) o siempre está tratando de mejorar su velocidad (aumentar la
utilización)?
Para hacer cualquiera de estas cosas, no podemos permitirnos el lujo de separar
a los desarrolladores del diseño. Las versiones actuales de las técnicas ágiles
populares incorporan mecanismos para dividir a los desarrolladores de la visión
de su producto. Nuestro objetivo original con Agile era liberar a los
programadores. En cambio, hemos cerrado el círculo. Los maestros de Scrum se
han convertido en gerentes de proyectos; los propietarios de productos se han
convertido en gerentes de productos. Hemos recreado una cascada con ropa de
Scrum.
El Método Kanban, Kanban Personal, Scrum (Tipos A, B, C), Scrumban, SAFe,
RUP, XP... ninguna de estas cosas es LA respuesta. No hay nadie, una sola respuesta.
Si lo hubiera, sería obvio y todos lo haríamos. Tomados solos, estos enfoques son
tan saludables como una cena preenvasada de microondas. Cuando estas y otras
técnicas se utilizan como ingredientes, entonces usted puede hacer una comida
real.
No habría Kanban hoy en día sin Kent Beck, Eliyahu Goldratt, Taiichi Ohno y W.
Edwards Deming. Las experiencias de David, Corey y mía en el lanzamiento de
Kanban fueron en sí mismas el producto de aprender y prestar atención, de
combinar muchas ideas en una sola.
Del mismo modo que un manual del conductor de Tokio no le dirá exactamente
cómo conducir en Akron, los métodos e ideas mencionados anteriormente no le
dirán exactamente cómo dirigir sus proyectos si se utilizan de forma aislada. Para
dirigir, hay que prestar atención. Para prestar atención, usted necesita ver su
trabajo y reducir las distracciones.
Lean y Kanban le ayudarán a hacer estas cosas, pero son frustrantes.
Por qué?
Porque es probable que usted y su equipo estén sobrecargados de trabajo y no
tengan el tiempo o incluso el permiso para prestar atención o cambiar su entorno
de trabajo. Los sistemas Lean abiertos son, por lo tanto, difíciles de poner en
marcha. Usted necesita tener una dirección clara y descripciones de trabajo para
los miembros de su equipo, sus jefes y otras partes interesadas. ¿Quién tiene tiempo
para eso?
Ahí es donde entra en juego este libro.
Ajay está llevando las ideas de Corey un paso más allá, proporcionando más
implementaciones potenciales para equipos que preferirían tener éxito que ser
seguidores ciegos de procesos enlatados. Este libro le ayudará a prestar atención, a
ver el trabajo que está asumiendo, a demostrar a otros la carga con la que está
lidiando y a comenzar a tomar el control de su trabajo en proceso. Pero no te
detengas aquí: Ajay lo llama (r)evolución a propósito. La evolución es un proceso
continuo.
Piensa en este libro como ese primer rayo de luz al final del túnel. Pero
recuerde, simplemente ver que la luz no es suficiente: necesita seguir adelante,
seguir mejorando sus procesos y seguir creando y manteniendo el mejor producto
posible.
El software nunca duerme.

-Jim BensonAutor
del Kanban Personal
ganador del Premio Shingo:
Mapping Work | Navigating Life
Ocean Shores, Washington
Prefacio

Aunque Scrumban ha evolucionado como un marco a través de los años, no tiene

una guía o definición definitiva. De hecho, como se destacó al principio de este
libro, varias fuentes "autorizadas" no están de acuerdo sobre lo que Scrumban
realmente representa. Scrumban se merece algo mejor.
El objetivo de este libro es transformar un conjunto confuso de
representaciones conflictivas en un recurso integral, coherente y práctico que
aporte valor a las personas y organizaciones que deseen aprovechar el poder de
Scrumban en sus propios entornos. Este libro no trata de nuevos avances en el
pensamiento, sino más bien de demostrar cómo un amplio conjunto de principios
Lean y Agile probados pueden ser efectivamente entretejidos y manejados dentro
del contexto de un solo marco. En el mismo sentido, no es un libro de recetas.
Aunque incorpora recomendaciones y consejos de práctica, este libro está pensado
principalmente como una guía para permitir a individuos y organizaciones
expandir su pensamiento de manera que apoye efectivamente sus objetivos finales.

Cómo usar este libro

Hay un par de estrategias diferentes para abordar este libro. Antes de abordarlas,
consideremos los diferentes niveles de aprendizaje.
Los nuevos profesionales quieren buscar pasos concretos para implementar y
seguir. Scrumban presenta un par de desafíos únicos para estos estudiantes de
"nivel Shu". En primer lugar, pide a los profesionales que se involucren en el
pensamiento sistémico y que reconozcan la noción de que no podemos mejorar los
sistemas de los que formamos parte sin obtener primero una comprensión
holística de esos sistemas. En segundo lugar, aunque algunas de las prácticas y
principios de Scrumban se prestan a definir pasos concretos, la mayoría no lo
hacen. En consecuencia, se pedirá a los alumnos que adopten los pasos concretos
que representan bloques de construcción incrementales para una comprensión
más amplia.
Ahora, las dos estrategias. La que elijas depende de lo que quieras sacar de este
libro:
Si estás interesado en entender el panorama general y quieres dominar
Scrumban en todo su contexto (algo que te recomiendo encarecidamente),
entonces el camino a seguir en este libro de principio a fin es el camino a
seguir. Si te encuentras leyendo algo que crees que es irrelevante o que te
pone a dormir, entonces, por supuesto, salta adelante. Pero no sugiero hacer
esto con demasiada frecuencia; es especialmente importante lograr una
comprensión integral de todo el contexto para ayudar a los nuevos
practicantes a evitar los escollos comunes.
Si está interesado en aprender más sobre un tema específico, puede ir
directamente al capítulo que lo cubre. Cada capítulo es un vehículo
autónomo de conocimiento sobre un tema amplio, pero los capítulos
también están ordenados para dar un sentido de continuidad al viaje que es
Scrumban.
 A lo largo del libro he rociado historias sobre cómo los equipos y las
organizaciones han utilizado Scrumban. En algunos casos, los equipos u
organizaciones aceleraron su dominio de las funciones y prácticas de Scrum. En
otros casos, Scrumban sirvió como un camino alternativo a la Agilidad (lo que
significaba que los equipos que seguían este camino ya no practicaban Scrum).
Ambos tipos de resultados arrojaron resultados pragmáticos y fundamentales, lo
que más preocupa a los equipos y a las organizaciones. Si no te importan estas
cosas, entonces este libro no es para ti.
Aunque este libro se centra predominantemente en el desarrollo de software, el
marco Scrumban puede ser adoptado en una variedad de funciones de negocio,
facilita lenguajes y entendimientos compartidos, e integra y alinea los esfuerzos de
manera efectiva. Este aspecto del marco de trabajo es particularmente relevante
para los desafíos asociados con el escalamiento de las prácticas Lean y Ágiles en
toda la empresa, y es lo que en última instancia hace que Scrumban sea tan
poderoso.

Cómo está organizado este libro

Este libro está organizado en cuatro secciones principales, cada una de las cuales
consta de varios capítulos.
Parte I, Introducción
Capítulo 1, Manifestaciones: Scrumban desmitificada
Una visión general de los orígenes de Scrumban y los estados actuales de
entendimiento en los círculos Lean y Agile.
Parte II, Fundamentos - Empezar con el fin en mente
Los capítulos 2, 3 y 4 tienen por objeto proporcionar a los lectores una
visión holística de las raíces de Scrumban y las razones para emplearla. La
naturaleza holística de estos capítulos hace que el material sea relevante
para todos los niveles de aprendizaje (Shu, Ha y Ri-I'll hablarán más sobre
estos niveles en el Capítulo 1), pero especialmente para gerentes y
ejecutivos. Debido a que los entendimientos fundamentales profundos en
todos los niveles conducen a mejores resultados, animo a las personas a
nivel de equipo a que eviten hacer caso omiso de estos capítulos,
especialmente del Capítulo 2.
Capítulo 2, La Matriz y el Desorden: Donde Todo Comienza
En este capítulo se presentan consideraciones clave que a menudo no se
reconocen en la búsqueda de mejoras. Visito factores históricos que a
menudo influyen en el desempeño de las organizaciones de TI, exploro
por qué los esfuerzos para volverse ágiles (lo que a menudo implica la
introducción de Scrumban en un entorno) pueden estancarse o fracasar,
y cómo Scrumban está generalmente estructurado para ayudar a superar
estos impedimentos.
Capítulo 3, La Misión: Aclarar la relación entre el propósito, los
valores y el rendimiento
Las organizaciones tienen más éxito cuando maximizan la alineación de
los esfuerzos en cuatro áreas clave. En este capítulo, destaco cómo se
 puede utilizar Scrumban para mejorar la alineación organizacional en
todas las funciones de la empresa.
Capítulo 4, Motivaciones: Por qué funciona Scrumban
¿Por qué Scrumban? Echo un vistazo más de cerca a los principios y
prácticas fundamentales que hacen de Scrumban un marco tan robusto
para mejorar la satisfacción de los trabajadores y crear un alto
rendimiento.
Parte III, Ejecución - Poner en práctica el Scrumban
Los capítulos 5, 6 y 7 son donde el caucho se encuentra con el camino,
enfatizando el "cómo" frente al "por qué". Debido a que desaliento
fuertemente a los nuevos practicantes de sumergirse en el "cómo hacerlo"
con poca comprensión del "por qué", los lectores encontrarán una cantidad
significativa de material explicativo incrustado dentro del contenido que
pretende servir como guía práctica.
Capítulo 5, Movilizar: Despliegue de Scrumban
Una mirada de cerca a un enfoque para poner en marcha Scrumban
dentro de un equipo u organización.
Capítulo 6, Método: Trabajando bajo la capucha
Una exploración concreta de cómo los valores, principios y métodos
específicos de Scrumban pueden ser aplicados y utilizados en diferentes
etapas de adopción.
Capítulo 7, Medidas: Obtención de información y seguimiento del
progreso
Las métricas en las que me baso para proporcionar una nueva
perspectiva y permitir una previsión más fiable.
Parte IV, Mejorando Temas y Prácticas Avanzadas
Los capítulos 8, 9 y 10 representan el pensamiento avanzado, un curso de
nivel "graduado". Es menos probable que los profesionales no
experimentados comprendan plenamente la relevancia y el poder de los
temas discutidos, ya que esa comprensión sólo se logra cuando se
experimenta Scrumban en acción. No obstante, el contenido ofrece una
perspectiva de las muchas opciones y capacidades que el marco expone a lo
largo del tiempo.
Capítulo 8, Gestión: La gerencia está haciendo las cosas bien - El
liderazgo está haciendo las cosas bien
Aunque Scrumban no tiene que ser conducido de arriba hacia abajo para
lograr el éxito inicial, este capítulo revisa por qué un buen liderazgo es
esencial para mantener un alto rendimiento a largo plazo.
Capítulo 9, Maduración: Como un buen vino, Scrumban puede
mejorar con la edad
Enfoques que ayudan a los equipos a seguir madurando, y evoluciones
comunes que pueden encontrarse.
 Capítulo 10, Modelado: Para ir audazmente a donde pocos hombres
y mujeres han ido antes
Técnicas aún más avanzadas para una previsión más precisa y una
gestión adaptativa.
Apéndice, Más: Por la fortaleza del corazón
Un apéndice que contiene definiciones y material de referencia adicional.

Convenciones
He empleado un par de convenciones sencillas para ayudar a los lectores a navegar
a través de ciertas categorías de información. Por ejemplo, algunos temas son
especialmente adecuados para ejecutivos y para aquellos en funciones de gestión
de carteras o programas. Encontrarás ilustraciones de ejecutivos y gerentes que
introducen estos temas (he tomado prestadas estas ilustraciones de GetScrumban,
un juego en línea que co-creé como herramienta de entrenamiento).
Del mismo modo, "Sanjay" el entrenador dirigirá su atención a conceptos de
particular importancia, gritará trampas y trampas para los incautos y ofrecerá
consejos basados en experiencias que ayudarán a muchos equipos a utilizar
Scrumban en sus entornos.
También trato de hacerle saber cuando se abordan temas más avanzados para
que pueda elegir volver a visitarlos a medida que su comprensión crece con el
tiempo.
Agradecimientos

Este trabajo no habría sido posible sin las contribuciones y el apoyo de muchas
personas. En particular, me gustaría dar las gracias. . . .
. . mi querida esposa Diana, nuestros cuatro hijos y mi madre Susheela por su
apoyo exuberante y desinteresado para hacer posible este trabajo.
. . mi amigo y colega de CodeGenesys, Jack Speranza, por su ayuda para hacer
posible este libro. Como Director de Operaciones de CodeGenesys, proporcionó
una perspectiva pedagógica al presentar el material de este libro a una variedad de
audiencias.
. . . Marc Hughes, mi amigo y socio, y mi equipo de ScrumDo por apoyar este
trabajo con datos y análisis invaluables.
. . clientes de CodeGenesys y ScrumDo.com que nos dieron permiso para
compartir sus historias.
. . otros colegas de CodeGenesys -especialmente Haritha y Bernard- por su
apoyo y ayuda.
. . . Dimitar Bakardzhiev y Frank Vega por sus valiosos comentarios.
. . . David Anderson, Jim Benson y Russell Healy por su amable apoyo.
. . . Corey Ladas, creador de Scrumban, sin el cual este libro obviamente no
podría existir.
. . y los miembros demasiado numerosos para nombrar a las comunidades Lean
y Agile que acordaron permitirnos incorporar porciones de su trabajo y siempre
están haciendo muchas contribuciones para el bien común.

-Ajay ReddyBoston
, Massachusetts
Sobre el autor

Ajay Reddy ha estado ayudando a los equipos de tecnología y a las organizaciones

a mejorar su funcionamiento durante más de una década. El énfasis en un enfoque
práctico y la experimentación colaborativa, la verificación de los resultados
empresariales y la mejora de la satisfacción del equipo son un sello distintivo de
sus compromisos.
Ajay comenzó su trayectoria profesional como ingeniero de software, un rol en
el que fue expuesto por primera vez a enfoques ágiles como Extreme
Programming. Pronto pasó a entrenar a otros en la adopción de mentalidades y
prácticas ágiles, buscando constantemente maneras de mejorar este proceso
basado en la variedad de desafíos asociados con diferentes entornos.
Ajay fundó CodeGenesys, una boutique de consultoría Lean-Agile, en 2009. En
2010, co-desarrolló ScrumDo, una herramienta de gestión de Scrum y Kanban, con
el propósito expreso de facilitar las implementaciones ágiles en toda la industria.
Durante los últimos cinco años, ha ayudado a organizaciones grandes y pequeñas a
emplear Scrumban con gran éxito. Ajay cree que Scrumban es un marco
particularmente simple, pero poderoso con una gran cantidad de potencial sin
explotar. Además de escribir este libro, recientemente co-creó el juego
GetScrumban como una ayuda práctica y efectiva para ayudar a individuos y
organizaciones a orientarse a las verdaderas capacidades de este marco.
Como principal estratega de productos y entrenador principal de ScrumDo, Ajay
está ayudando a equipos y organizaciones de 145 países a darse cuenta de los
beneficios de Scrumban. Enseña Scrumban en los Estados Unidos, India y Europa, y
es un orador habitual en las reuniones y conferencias de Scrum y Kanban en todo
el mundo.
En 2012, Ajay se desilusionó con el debate sobre los marcos, ya que consideraba
que ponía demasiado énfasis en los marcos más que en los sistemas humanos y en
las preocupaciones empresariales que esos marcos se crearon para facilitar. Cree
que el uso de marcos como herramientas para apoyar eficazmente los resultados
deseados es más importante que la mecánica de cualquier marco. Fue esta
comprensión la que lo llevó directamente a pasar los últimos dos años escribiendo
este libro.
Ajay Reddy vive en Massachusetts con su esposa, Diana, y sus cuatro hijos.
Puede encontrarlo en Linkedin, en www.ajayreddy.net, en codegenesys.com, en
www.scrumdo.com, y como @ajrdy en Twitter.
Parte I: Introducción
Capítulo 1. Manifestaciones: Scrumban
desmitificada

Estimo que el 75% de las organizaciones que usan Scrum no tendrán éxito
en obtener los beneficios que esperan de él..... Scrum es un marco muy
simple dentro del cual se juega el "juego" del desarrollo de productos
complejos. Scrum expone cada inadecuación o disfunción dentro de las
prácticas de desarrollo de productos y sistemas de una organización. La
intención de Scrum es hacerlos transparentes para que la organización
pueda fijarlos. Desafortunadamente, muchas organizaciones cambian
Scrum para acomodar las insuficiencias o disfunciones en lugar de
resolverlas.
-Ken Schwaber, co-creador de Scrum

Scrum es un marco de desarrollo de software increíblemente sencillo, eficaz y

popular; su valor aumenta a medida que los equipos y las organizaciones
desarrollan su comprensión y aplicación de sus principios y prácticas
fundamentales.
A pesar de su simplicidad, Scrum puede ser difícil de dominar. Si bien capacita
tanto a los individuos como a los equipos para descubrir los factores que impiden
la Agilidad y abordar cómo deben ser abordados, se basa en su motivación
colectiva, esfuerzo y capacidades para hacer que esto suceda. Toda una industria
existe ahora en torno a la prestación de servicios para ayudar a las personas, los
equipos y las organizaciones a alcanzar niveles más altos de capacidad.
Scrumban es también un marco sencillo. Es un recién llegado al mundo del
desarrollo de software y aún no ha evolucionado completamente; también es a
menudo malinterpretado por la gente en los círculos Lean y Agile. Mucha gente
nunca ha oído hablar de él. Algunos creen que no es más que el uso de sistemas de
kanban virtual dentro del marco Scrum, mientras que otros creen que es un nuevo
marco de desarrollo de software que combina "los mejores" elementos de Scrum y
el Método Kanban. Ninguno de estos puntos de vista captura la verdadera esencia
de Scrumban.

Una perspectiva útil

A principios de los años 2000, Alistair Cockburn introdujo el "Shu-Ha-Ri" en el
mundo del desarrollo de software. Proporcionó una manera de pensar acerca de
las tres fases distintas por las que las personas pasan cuando dominan una nueva
habilidad o concepto. Cockburn tomó prestado este concepto de las artes marciales
japonesas y creyó que podría ser aplicado efectivamente dentro del contexto de
mejorar los procesos y prácticas de desarrollo de software.
Los invito a abrazar un estilo de aprendizaje que se basa vagamente en el Shu-
Ha-Ri para aprender a entender el Scrumban. Repasemos rápidamente las tres
etapas:
 Shu (Principiante): La primera etapa del aprendizaje. Los nuevos
estudiantes buscan reproducir un resultado dado siguiendo un conjunto de
instrucciones que se centran en la práctica. Se centran en cómo realizar una
tarea con una comprensión básica de los principios subyacentes. El éxito en
esta etapa se mide por si un procedimiento funciona y qué tan bien entiende
el estudiante por qué funciona.
Ha (Intermedio): Una vez que el estudiante ha dominado las prácticas,
valores y principios básicos, comienza a identificar los límites de estas
prácticas y técnicas. El estudiante busca expandir su conocimiento de
enfoques alternativos, aprendiendo cuando una alternativa se aplica y
cuando se rompe. El éxito en esta etapa se mide por lo bien que el
estudiante aprende a aplicar las capacidades de adaptación a diversas
circunstancias.
Ri (Avanzado): El estudiante se ha convertido en un maestro. Ya no importa
si él o ella está siguiendo un procedimiento o una práctica determinada. Su
conocimiento y comprensión son el producto de pensamientos y acciones
repetidos. El máster ha desarrollado una capacidad de adaptación total en el
contexto de su experiencia en el medio ambiente. El éxito se mide por los
resultados consistentemente exitosos.
Los lectores informados no deben confundir el concepto de Shu-Ha-Ri con algo
como el programa de capacitación y evaluación para la mejora de procesos de
Integración de Modelos de Madurez de Capacidades (CMMI) de la Universidad
Carnegie Mellon. Aquellos que adoptan y practican los principios de Scrumban no
estarían tan inclinados a dirigir duras críticas al modelo como lo han hecho
algunos individuos en los círculos Lean y Agile.
Aunque no estoy de acuerdo en que los "destinos" o "características" prescritos
por CMMI se correlacionen con la capacidad en todos los contextos, este modelo
presenta un menú de catalizadores potenciales para emplear en un marco
Scrumban cuando se persiguen los resultados de negocio deseados. Visto desde la
dirección opuesta, las capacidades de gestión de flujo que Scrumban permite
pueden proporcionar un catalizador útil para las organizaciones que buscan
niveles prescritos de capacidad CMMI para lograr los resultados deseados.

Un marco para la[R]Evolución

Cuando Corey Ladas presentó al mundo a Scrumban en su libro seminal, Essays on
Kanban Systems for Lean Software Development (Ensayos sobre sistemas Kanban
para el desarrollo de software lean) (Modus Cooperandi Press, 2009), definió a
Scrumban como un método de transición para trasladar los equipos de desarrollo
de software de Scrum a un marco de desarrollo más evolucionado. Durante los
últimos cinco años, mi propia investigación y experiencia laboral han revelado las
muchas maneras en que Scrumban ha evolucionado.
Desde que Corey escribió su libro, las organizaciones han colocado el Método
Kanban en capas junto con Scrum para ayudarles a lograr diferentes tipos de
resultados. Por ejemplo, he ayudado con éxito a organizaciones a aplicar los
principios y prácticas de Scrumban en una variedad de contextos -desde empresas
nuevas hasta empresas de Fortune 50, en industrias que van desde servicios
profesionales hasta el desarrollo de productos de software. A través de estos
contextos, he usado Scrumban para los siguientes propósitos:
Ayudar a los equipos y organizaciones a acelerar su transición a Scrum desde
otras metodologías de desarrollo
Habilitar nuevas capacidades dentro de los equipos y organizaciones para
ayudarles a superar los retos que Scrum (intencionadamente) les hace
enfrentar.
Ayudar a las organizaciones a desarrollar nuevos procesos y prácticas
similares a Scrum que funcionen para ellas, no para acomodar las
insuficiencias y disfunciones que Scrum expuso, sino más bien para
resolverlas de la manera más efectiva para su entorno único.
Estas experiencias demuestran que Scrumban ha evolucionado hasta
convertirse en una familia de principios y prácticas que crean herramientas y
capacidades complementarias. Y como cualquier organismo vivo, estos principios y
prácticas continuarán evolucionando a medida que los practicantes comparten sus
experiencias y aprendizajes.
Ahora, consideremos los tres resultados diferentes resumidos anteriormente en
el contexto del Shu-Ha-Ri:
Scrumban proporciona la disciplina y la estructura que necesitan los
practicantes en la fase de aprendizaje de Shu. El marco de trabajo de
Scrumban permite a los equipos y organizaciones gestionar la introducción
de los artefactos y ceremonias de Scrum o las métricas mejoradas y las
prácticas de gestión de flujos de las disciplinas y estructuras Kanban que los
nuevos alumnos necesitan de forma limitada.
Por ejemplo, las ceremonias de Scrum son esenciales para crear los
niveles deseados de rendimiento y agilidad. Aunque es un marco
relativamente simple, Scrum puede parecer abrumador cuando se introduce
por primera vez. En un esfuerzo equivocado para facilitar la adopción,
muchas organizaciones modifican u omiten las ceremonias o, lo que es peor,
ignoran la importancia de comprender los principios y valores básicos. Esto
rara vez, o nunca, produce los resultados deseados.
Las capacidades adicionales proporcionadas por el marco Scrumban
pueden sustituir a las funciones que sirven las ceremonias Scrumban
modificadas u omitidas. Las visualizaciones de Scrumban y otros
mecanismos mejoran la efectividad mientras reducen el tiempo y el
esfuerzo asociados con la realización de ceremonias. Scrumban conecta más
eficazmente la práctica de las ceremonias con los principios y valores a los
que sirven las ceremonias.
Scrumban expone nuevas herramientas y capacidades que ayudan a los
experimentos y descubrimientos perseguidos en la fase Ha. Cumplir con los
desafíos que los equipos y las organizaciones enfrentan comúnmente al
implementar Scrum u otras prácticas ágiles representa un aspecto de esta
dimensión.
Considere la posibilidad de crear y administrar una cartera de productos.
Este artefacto de Scrum, y los eventos que lo rodean (sesiones de
 preparación y planificación), tiene como objetivo gestionar el riesgo y
optimizar el valor al permitir una mejor toma de decisiones debido a la
maximización de la transparencia y la comprensión del trabajo. Esto puede
ser especialmente frustrante cuando las organizaciones asignan
efectivamente a múltiples propietarios de productos a una cartera porque
las limitaciones individuales interfieren con la realización de un conjunto
completo de capacidades, o debido a las amplias variaciones en las
evaluaciones subjetivas.
El framework Scrumban visualiza información e integra capacidades que
otros frameworks no proporcionan de forma inherente. Ayuda a
proporcionar una mejor comprensión contextual y mide con mayor
precisión el resultado de los diferentes enfoques (apelando directamente a
la práctica y la comprensión de la fase Ha). Por ejemplo, Scrumban visualiza
todas las fuentes de demanda de trabajo y un impacto económico más
objetivo a lo largo del tiempo (costo del retraso) para ayudar a priorizar el
trabajo, dando mayor transparencia al panorama general y ampliando las
formas de adaptación.
Scrumban es lo suficientemente flexible como para proporcionar a los
maestros de Ri-level un proceso robusto dentro del cual operar a niveles de
hiperactuación. Al enfatizar el pensamiento sistémico, la experimentación y
el descubrimiento, los maestros de Ri-level son libres de moldear sus
formas de trabajar de cualquier manera que produzca los mejores
resultados, tanto desde el punto de vista del rendimiento como de la
satisfacción de los trabajadores. No importa si el proceso resultante se
ajusta a un conjunto particular de prácticas.
Scrumban apoya tanto la "revolución" como la "evolución". Y lo que es más
importante, está estructurado de una manera que apoya firmemente todos
los niveles de aprendizaje y comprensión, a un nivel de calidad que es
mayor que el proporcionado por Scrum o Kanban solamente.
Todas las capacidades añadidas de Scrumban se pueden aplicar opcionalmente a
un contexto de Scrumban de varias maneras. También pueden extenderse a
múltiples áreas de una organización para lograr mejores resultados de negocio. El
marco de desarrollo de software de Scrum se encuentra en su base, al igual que el
Método Kanban. Sin embargo, ninguno de estos marcos representa un destino
prescrito para las organizaciones que practican Scrumban.
Más allá de representar una mentalidad significativamente evolucionada del
marco expresado por Ladas, el Scrumban actual es muy diferente de las
definiciones utilizadas por otros líderes respetados en la comunidad Lean/Agile.1
En muchos aspectos, estas perspectivas ven a Scrumban como un vehículo para
mover equipos de Scrum a otro proceso de desarrollo de software. Aunque este
sigue siendo un resultado potencial, las aplicaciones del mundo real demuestran
que Scrumban ha llegado a implicar más que esto en una amplia gama de
contextos.
1. Véase, por ejemplo, http://tiny.cc/badcomparisonsSK (julio de 2013).
A lo largo de los años, Scrumban se ha utilizado para ayudar a los equipos y
organizaciones a acelerar su transición a Scrum desde otras metodologías de
desarrollo. Se ha utilizado para ayudar a los equipos y organizaciones a superar
una variedad de desafíos comunes que Scrum está diseñado para forzarlos a
enfrentar. Cuando el contexto lo requiere, se ha utilizado para ayudar a las
organizaciones a desarrollar nuevos procesos y prácticas similares a Scrum que
funcionen mejor para ellas, no simplemente como un medio para acomodar las
insuficiencias y disfunciones que Scrum expuso, sino más bien como una estrategia
para resolver esos problemas de la manera más efectiva para ese entorno. Este
último resultado obviamente no es algo que Scrum mismo proporciona. Estos
diferentes caminos reflejan la línea de fondo de Scrumban: el pragmatismo
orientado al servicio que la mayoría de las empresas valoran.
En última instancia, Scrumban se ha convertido en un marco de
empoderamiento. David J. Anderson, pionero del Método Kanban, declaró
recientemente:

El empoderamiento no consiste en dejar que la gente haga lo que

quiera, o asumir que de alguna manera se auto-organizará para
producir el resultado correcto. El empoderamiento se trata de definir
los límites, y hacemos lo mismo con los niños cuando los educamos; les
decimos cosas como cuándo es su hora de dormir, dónde pueden jugar,
si pueden salir fuera del patio de la casa, si pueden nadar en el extremo
poco profundo de la piscina, si no pueden saltar del trampolín.... todas
estas cosas. Por lo tanto, el empoderamiento consiste en dar a las
personas límites claros, y luego permitirles usar sus iniciativas dentro
de los límites.

2. http://tiny.cc/DavidAKanban (marzo de 2013).

Scrumban se distingue de Scrum porque enfatiza ciertos principios y prácticas
que son muy diferentes de los fundamentos tradicionales de Scrum. Estos incluyen
los siguientes:
Reconocer el papel de la administración (la autoorganización sigue siendo
un objetivo, pero dentro del contexto de límites específicos).
Habilitación de equipos y funciones especializadas
Aplicar políticas explícitas en torno a las formas de trabajo
Aplicando las leyes del flujo y la teoría de las colas
Scrumban se distingue del método Kanban en los siguientes aspectos:
Prescribe un marco de trabajo subyacente para el proceso de desarrollo de
software (Scrum) como su núcleo.
Se organiza en torno a equipos.
Reconoce el valor de las iteraciones de caja de tiempo cuando es apropiado.
Formaliza técnicas de mejora continua dentro de ceremonias específicas.
Deje de beber el Kool-Aid
Mike Cohn, un líder en la comunidad Agile/Scrum, recientemente"criticó" a3
equipos de Scrum por no estar"enfocados en encontrar soluciones innovadoras a
los problemas que se les presentan". En realidad no estaba criticando a Scrum; más
bien, estaba criticando una mentalidad que ha evolucionado entre los practicantes
de Scrum, una mentalidad que favorece un enfoque seguro para completar el
trabajo por encima de la innovación.
3. http://tiny.cc/cohnscrumcricism.
Veo un fenómeno relacionado en mis compromisos de coaching. El mayor
impedimento para la mejora suele residir en los miembros del equipo que no
pueden o no quieren pensar en mejorar la forma en que se realiza el trabajo (o en
cómo su trabajo es relevante para la creación de valor empresarial).
Creo que el problema es aún más profundo. Ha surgido un culto al Scrum que
impregna la industria que se ha desarrollado alrededor del Scrum. Los
profesionales de Scrum no sólo no buscan la innovación en su trabajo, sino que
también no buscan la innovación en el proceso. Scrum ha evolucionado a lo largo
de los años a medida que se descubría nueva información, pero parece haber una
creciente resistencia entre sus practicantes más ardientes a reflexionar sobre
cómo apoyar su propósito fundamental.
Vi esta renuencia recientemente durante una presentación a una comunidad
ágil en Boston. Al principio de la presentación, pregunté a la audiencia cuántos de
ellos estaban usando Scrum en sus entornos. Cerca de la mitad de los espectadores
levantaron la mano. Luego pregunté cuántos habían experimentado desafíos al
adoptar Scrum en sus organizaciones. Ni una sola mano bajó.
Cuando empecé a describir algunas de las formas alternativas en que Scrumban
permite que los equipos y las organizaciones logren sus propósitos deseados,
surgieron debates sobre si los enfoques prescritos o populares asociados con
Scrum eran ineficaces. A pesar de mi repetido énfasis en que Scrumban
simplemente representa caminos alternativos o adicionales cuando algún aspecto
del marco de trabajo de Scrum no está cumpliendo con su propósito en un contexto
particular, la mayoría de las personas en la sala -incluso aquellos que reconocieron
los desafíos con sus adopciones de Scrum- estaban más interesados en defender su
proceso existente que en considerar si un enfoque alternativo podría ayudarles a
superar un desafío.
Esta mentalidad de culto no se limita a la comunidad de Scrum. Elige tu método
o marco de trabajo y encontrarás muchos comportamientos similares, incluso en
Kanban.
Afortunadamente, la mayoría de los practicantes cotidianos son pragmáticos y
realistas. El simple pragmatismo y la voluntad de experimentar son las razones por
las que Scrumban ha evolucionado hasta convertirse en el marco descrito en este
libro. Desafortunadamente, siempre habrá un grupo marginal de "líderes de
pensamiento" que perpetúan los debates marco porque no están dispuestos a
promover los beneficios de un enfoque que "compite" con modelos en los que han
invertido cantidades significativas tanto de tiempo como de dinero. Scrumban
puede ser algo menos amenazador debido a sus elementos familiares, pero lo
criticarán de todos modos.
 Scrumban es un marco que casi obliga a sus practicantes a aceptar la realidad de
que las buenas ideas pueden venir de cualquier parte. Alienta a la gente a perseguir
activamente esta realidad en todo momento. La pregunta que los lectores deben
responder por sí mismos es si están listos para aceptar esta realidad y abrazar la
exploración, o si permanecerán atrapados dentro de una perspectiva más estrecha,
justificando esta mentalidad por la existencia de un "debate" que se perpetúa más
por miedo que por hechos.

Vamos a empezar
Una de las características más poderosas de Scrumban es el hecho de que puede
ser implementado en cualquier nivel de la organización - no se necesita la
autoridad de alguien al mando y el control para comenzar a hacer una diferencia
en la forma en que se trabaja (aunque ciertamente es más fácil si se tiene algún
grado de participación).4 También tiende a ser contagioso.
4. Esto puede ser cierto incluso en entornos en los que los procesos de desarrollo están sujetos a
auditoría, aunque la naturaleza y el alcance del cambio evolutivo pueden ser más limitados que en
contextos menos restrictivos.
Así que si su objetivo es que su empresa se convierta en líder del mercado o
simplemente para tener un mejor control sobre su propio entorno, le invito a
unirse al grupo Scrumban.io5 LinkedIn de la comunidad Scrumban o a
www.facebook.com/Scrumban y a seguir el blog de Scrumban en
www.scrumban.io.
5. El grupo Linkedin está disponible en www.theagilecollaborative.net, que redirecciona a
https://www.linkedin.com/groups/Scrumbanio-7459316.