Kanban Boxes: campos de scrum en oficinas multiproyecto

Implantar un campo de Scrum para un único equipo de 4 a 8 personas, que trabaja en el desarrollo de un único sistema es un “caso de libro”. No hay más que “copiar y pegar” las prácticas tradicionales de scrum de Ken Schwaber y Jeff Sutherland.

Pero en las empresas en las que nos movemos son bastante habituales los entornos multiproyecto, y “equipos” mínimos de tres, dos, o incluso una persona, y como flexibilidad consiste adaptar las prácticas a nuestra circunstancia y no al revés, os comento una práctica, de invención propia, que me está funcionando razonablemente bien, y que me ha dado por llamar “cajas kanban” o “kanban boxes”, que parece que inglés siempre mola más 😉

Mantiene los principios de “time boxing “, Seguimiento diario del avance, comunicación directa y visual, pero no hace dependiente el avance iterativo de ciclos temporales o “sprints” sino simplemente de nuevas funcionalidades, y es válida para entornos multi-proyecto, y también más aconsejable que el ciclo Scrum clásico para equipos muy pequeños (3 personas o menos)

¿Qué es una caja Kanban o una Kanban Box?

La descomposición y estimación de una funcionalidad o historia de usuario en las tareas que la componen, con un formato visual y simple (Kanban) y un indicador de avance diario ágil:

Y a partir de aquí, en función de cómo es nuestro equipo y los proyectos en los que estamos, vendría la gestión ágil: el arte de lo posible: cuál es el mayor valor que puede entregar el equipo de la empresa, con los criterios de prioridad de los responsables de producto, en el menor tiempo posible. Un ejemplo de uso:

Kanban Boxes

1.- Las diferentes pilas de producto se priorizan entre los diferentes “propietarios”, y teniendo en cuenta la capacidad de desarrollo. del equipo total de la empresa…

2.- …se van “encajando” las historias más prioritarias, y por tanto las próximas que van a entrar en producción.

3.- Cada caja constituye en sí un incremento para construirse de forma completa y operativa, y queda encolado a la espera del próximo “slot” para entrar en desarrollo.

4.- Al entrar al tablero Kanban de desarrollo, se calcula la velocidad prevista en función de la personas(s) que se la han asignado y a diario se actualizan las tareas y los indicadores de avance: el teórico y el real.
Ej: la caja tiene un tamaño de 35 puntos. Se la han asignado 2 personas y por la media de velocidad en la empresa (p. ej.: 4 puntos persona /día) la velocidad prevista de avance serían 8 puntos /día. Cada día se borran 8 puntos de la barra de velocidad teórica, y se actualiza la barra de velocidad real con los puntos que realmente queden por hacer.

Kanban Boxes

Para la comunicación en los puntos 1 y 2: priorización de la pila general de la empresa entre los diferentes propietarios, y descomposición y valoración de las tareas, respetad los principios ágiles de comunicación directa (socialización) y conocimiento y aportación conjunta del equipo a la visión del producto, estableciendo reuniones de características similares a las de inicio de sprint del ciclo clásico de scrum con los criterios de momento y participantes más adecuados según cada empresa.

Espero que os sirva de idea… Bienvenidas las sugerencias y mejoras!

La agilidad crece sola, y gusta.

Uno de cada tres programadores, o gestores que trabajan directamente en proyectos de programación usan metodologías ágiles, y las han incorporado por propia iniciativa, no por instrucciones “corporativas”. La implementación se produce “motu proprio” en equipos que trabajan en la misma planta o en el mismo edificio.  La metodología más empleada, con mucho, es Scrum; y la mayoría de los que las emplean hablan bien de ellas, y creen que han mejorado la comunicación en el equipo, la velocidad en el cierre de versiones y la flexibilidad en el diseño.

Estas son las principales conclusiones de uno de los pocos estudios realizados sobre una muestra de técnicos, significativa (492 encuestas anónimas). Lo realizó Microsoft hace 2 años entre su personal de EE.UU, Europa y Asia, para analizar el grado de “contagio” de agilidad que estaba teniendo la empresa, la opinión de los técnicos y los resultados.

Prácticas ágiles empleadas

Prácticas ágiles empleadas

Grado de satisfacción por el uso de prácticas ágiles

Grado de satisfacción por el uso de prácticas ágiles

BDD: la evolución del Desarrollo Dirigido por Tests (TDD)

Poner las pruebas (el testing) delante de la programación ha marcado un hito en las prácticas de programación, un antes y un después, que ha transfromado a la “cenicienta” del testing en princesa; de trabajo indeseado (probar lo que iban terminando los programadores) a tarea “cool” de diseño y pre-codificación.

TDD ha hecho que sean las pruebas las que tracen la pauta al desarrollo, y no al revés, y al hacerlo ha abierto dos dimensiones nuevas al testing tradicional: documentación, y sobre todo: diseño:

  • Se empiezan a escribir pruebas unitarias con herramientas como JUnit o NUnit.
  • Empieza a aumentar la confianza en el código, en la misma proporción que el volumen de pruebas que se va generando.
  • Al escribir las pruebas en primer lugar, el código gana simplicidad, programándose lo extrictamente necesario.
  • Las pruebas van tomando una nueva dimensión: “documentación”, porque cuando se retoma código ya olvidado,  son las que mejor explican qué es lo que hace ese código.
  • Poco a poco se empieza a descubrir la segunda dimensión: desarrollar pruebas revela el “API” del código, y pasa entonces a ser también un proceso de diseño.

A partir de este punto se empieza a plantear olvidar el origen de TDD, quitar el foco del “testing” de unidades de código, y llevarlo hacia diseño y comportamiento funcional, pasando de TDD a BDD (Behaviour Driven Development)

Básicamente es lo mismo, pero con unos cambios clave: La unidad de prueba ya no es una unidad de código (unit) sino un comportamiento. Los estados pasan a comportamientos y los marcos “xUnit” a “rSpec”.

La verdad es que en nuestra industria la espiral de conocimiento está girando muy deprisa. Si tuviéramos que dibujar su avance en el campo del testing podría ser algo así:

Evolución del testing

Más información

Herramientas BDD

Scrum Manager: Campo de Scrum en toda la empresa

El concepto original “Campo de Scrum” definido por Nonaka y Takeuchi describe un entorno de trabajo con principios ágiles en equipos motivados, con delegación y  “empowerment”, que desarrollan proyectos de forma iterativa a incremental, que no dividen el ciclo de desarrollo en fases, comparten el conocimiento por socialización (comunicación directa)…

La implementación de un campo de scrum no depende de las prácticas empleadas (Backlog Burndown / historias de usuario / Etiquetas kanban …) o del ámbito de aplicación (proyecto, producto o empresa).

La implementación que Jeff Sutherland realizó en 1993 en su equipo en Easel Corporation, a nivel de proyecto, que Ken Schwaber  documentó, en el libro Agile software development with scrum y que difunde la Scrum Alliance, es una implementación concreta, como lo son tambien cada una de las desarrolladas originalmente por Canon, NEC, Xerox, hp, Honda,  Epson… Es buena, pero nada impide diseñar un campo de scrum con flexibilidad en las prácticas para  adecuarlas a cada realidad, y con ámbito de proyecto, producto o de empresa, según sea para un equipo, departamento (por ejemplo de I+D en una software factory de procesos), o de organización en su conjunto.

Tomando el concepto original de Scrum y “des-monopolizándolo” de la Scrum Alliance, es posible plantear implementaciones con diferentes prácticas y también a nivel de producto o de empresa. Con esta visión de Scrum Manager la agilidad da su mejor resultado cuando se implican y alinean los diferentes ciclos de la empresa: estratégico, proyectos y producción.

Continue reading “Scrum Manager: Campo de Scrum en toda la empresa”

Motivación: mejor intrínseca que extrínseca

Scrum Manager bit: La motivación extrínseca es adecuada en trabajos relativamente mecánicos y entornos industriales, pero puede ser contraproducente en empresas del conocimiento.

Ambiente Industrial Campo de Scrum
Los principales responsables de la calidad del resultado son los procesos y la tecnología Los principales responsables de la calidad del resultado son las personas
Fábrica

cc by cloneofsnake

campo_scrum

cc by Dan Zen

Las personas ayudan a los procesos y la tecnología Los procesos y la tecnología ayudan a las personas
La mayoría de principios y prácticas de gestión en cualquier nivel y en sus relaciones (empresa, proyecto o producto) son diferentes.
La motivación extrínseca es una prescripción relativamente válida para los primeros, y  normalmente contraproducente para los campos de Scrum.

Safe Creative #1001035242501

¿Modelo de Madurez de la Capacidad de los equipos?

equipo_baloncesto_1909Con el principio de calidad de Juran, el protagonismo del resultado lo tienen los procesos: “La calidad del resultado depende de los procesos empleados en su fabricación”

Con el principio de agilidad, el protagonismo del resultado lo tienen las personas trabajando en equipo: “Preferimos el valor de los individuos y su interacción, por encima de los procesos y las herramientas”

La apuesta de aplicar el primer principio para mejorar los resultados de la fabricación de software, viene desarrollando desde los 90 modelos de “Madurez de la Capacidad de los Procesos” (CMM’s) tomando por capacidad de un proceso, el grado de eficiencia con el que logra el resultado que se espera de él.

Parece lógico pensar que sobre el principio de agilidad se debería desarrollar la “Madurez de la Capacidad de los Equipos”  (MMCE… ¿Modelo de Madurez de la Capacidad de los Equipos?)

Aunque pueda parecer lo contrario, los procesos son fáciles, la agilildad no.
Aplicando las prácticas del modelo CMMI se logran los objetivos de las áreas de procesos y con ellos, procesos de alta capacidad.
Aumentar la capacidad de las personas, y de éstas trabajando en equipo es algo más complicado. Aplicando prácticas ágiles no se logran equipos de alta capacidad.

La empresa como “campo de Scrum”

¿Por qué no aplicar Scrum en toda la empresa considerando a la organización en su conjunto, como un todo sistémicamente relacionado?

¿Por qué acomodar la empresa a la “forma” del modelo?: Sea la forma de Scrum o de DSDM o de CMMI. ¿Por qué no considerar a las formas como lo que son, y emplear los fondos de conocimiento que hay tras ellas para componer un modo de trabajo apropiado a las características de la empresa y de sus proyectos?

Scrum puede “implantarse” (forma) o “institucionalizarse” (fondo); y proporciona mayores cotas de agilidad cuanto más ágil es la empresa en su conjunto.

Poner un ScrumMaster en el departamento de programación de una empresa con visión y cultura apuntando en otra dirección, o sencillamente sin visión; con un área de RR.HH. no alineada hacia una gestión de personal ágil (gestión del conocimiento); con un departamento de marketing o de producto sin implicación en roles de propietario de producto; con áreas administrativas y comerciales trabajando sobre patrones de contratos de planificaciones cerradas… es una combinación peligrosa que suele producir empresas fragmentadas.

Más que aplicar una “forma” para el área de desarrollo se trata de gestionar la empresa en su conjunto desde los principios de agilidad. Es más una tarea de “Scrum Manager” que de “Scrum Master”.

Scrum Management

Continue reading “La empresa como “campo de Scrum””