Evitando la seducción de la herramienta

seduction-2

Durante mi charla en Ágiles 2015 presenté una lámina para ilustrar un par de conceptos interesantes tomados del libro High Altitude Leadership de Chris Warner and Don Schmincke relacionados al cambio organizacional y a los desafíos de los Líderes de Cambio. De entre ocho peligros a los que se enfrentan los líderes en busca de sobrevivir a la escalada de la montaña, quiero enfocarme en este post en el peligro #3: la Seducción de la Herramienta.

La imagen a continuación -que es mi representación del entendimiento de estos conceptos del libro- muestra de forma sencilla los aspectos que afectan al comportamiento organizacional y su influencia en la cultura, básicamente es otra forma de representar la dinámica de la cultura organizacional.

High Altitude Leadership

Conocemos que nuestro sistema de creencias influencia nuestro comportamiento: nuestra conciencia de identidad, el cúmulo de valores y principios inculcados en nuestra infancia, lo aprendido de nuestros padres y la sociedad. Pero no es lo único que afecta el comportamiento. Dentro del contexto organizacional, el «Qué» –representado como la estructura o jerarquía actual, el enfoque de planificación, establecimiento de objetivos, la definición métricas y su objeto de medición– más el «Cómo» que son los procesos, políticas y mecanismos actuales de a través la organización ejecuta– influencian fuertemente y dibujan un comportamiento. Ambos definen la forma de cómo viaja la información y cómo se interpreta.

Lo que se espera es que a través de este comportamiento se generen resultados, y que estos sean cada vez mejores para el bienestar de la organización (y su supervivencia). Entre el comportamiento y los resultados normalmente se usan herramientas que sirven de «habilitantes» (enablers) que brindan soporte durante la ejecución y al posterior cumplimiento de objetivos.

¿Qué es la Seducción de la herramienta?

«Las herramientas ofrecen esperanza, y hacen sentir a las personas que tienen la respuesta correcta. Pero hay problemas cuando los empleados usan las herramientas como muletillas para tener respuestas seguras. Ambos, escaladores muertos y compañías en banca rota fueron encontraron agarrando grandes herramientas.»

– Chris Warner and Don Schmincke, High Altitude Leadership

Es ser seducido por la ilusión de que la herramienta produce resultados en lugar que las personas. Es pensar que la herramienta en sí misma es la solución; es cuando la herramienta nos deslumbra, nos impresiona, nos «enamoramos» de ella. El problema radica en que fácilmente se puede perder la perspectiva y dejar de pensar en el propósito, la problemática y el contexto general. En muchos situaciones, sobre todo en grandes organizaciones, se tiende a pensar que entre más cara o sofisticada o completa parezca ser la herramienta ésta es mejor.

Esto normalmente sucede cuando las últimas herramientas para el cambio organizacional, desarrollo de liderazgo, mejora de procesos, métodos de gestión -y por supuesto, frameworks para la adopción de Agile a nivel empresarial- distraen nuestra atención de los aspectos vitales. En lo relacionado a Enterprise Agile, no se trata de la adopción de un framework específico, sino de lograr la agilidad del Negocio (y un poco más allá).

 

Algunas evidencias de que esto está sucediendo en la organización incluyen:

  • Equipos trabajando para la herramienta en lugar de la herramienta trabajando para los equipos;
  • Contar con mucha información nueva e interesante pero irrelevante;
  • Síndrome del «Consultor de la Semana» (uno más experto que otro en la herramienta);
  • Nuevas ideas pero sin la capacidad de producir resultados;
  • Muchas reuniones inútiles;
  • El cumplimiento de tareas se confunden con resultados.

«En montañismo, la seducción de las herramientas ponen en peligro a los escaladores cada vez que se visten con la mejor ropa y últimos equipos, pero que aplican comportamiento y técnicas equivocadas para el desafío. En su exceso de confianza (o novatada), terminan perdidos durante días en una pendiente devastada por una tormenta, mientras que los escaladores experimentados están en el campamento base tomando cerveza y viendo el clima. Del mismo modo, el peligro de un ‘desfile de expertos’ empaquetando y vendiendo las últimas herramientas pueden distraer a los equipos.»

– Chris Warner and Don Schmincke, High Altitude Leadership

La herramienta adecuada para el problema adecuado

«Un tonto con una herramienta sigue siendo un tonto.»

-Grady Booch

Por supuesto, las herramientas son importantes; pero deben poder usarse inteligentemente y mucho de esto radica en identificar el problema correcto. Imagine que le pido pintar un paisaje en una hoja de tamaño A4; se podría usar lápices o crayones o acuarela y pincel (mi hija es una profesional en esto). Imagine ahora que le pido pintar un paisaje en una pared de 25mX8m, si bien es cierto que podría usar pinceles o todo lo anterior, pero puede ser más efectivo usar una brocha o un rodillo o un soplete, o los tres; y esto no significaría que un rodillo es mejor que un pincel; cada una es útil en el contexto apropiado.

Lo mismo ocurre con los frameworks para escalamiento de Agile (LeSS, DAD, SAFe, Nexus, Scrum, etc.). Cada uno ofrece mecanismos interesantes que son más útiles para ciertos contextos, y muy probablemente pueda usar elementos de más de uno. El punto clave del asunto es identificar cuál es más adecuada para el contexto actual y cómo puede aportar efectivamente al cumplimiento del propósito: Agilidad Empresarial. Scaling Agile no es igual a Enterprise Agile. Enterprise Agile responde a buscar Agilidad en el Negocio, Agilidad Organizacional y Cultura Ágil viva. Por lo que la adopción de frameworks son simplemente formas de apalancar a los equipos en la consecución de este propósito, de lograr pintar la pared.

¿Cómo evitar la Seducción de la Herramienta?

«De la misma forma que la música proviene del músico y no del instrumento; Agilidad proviene de las personas y no de los frameworks.”

-Johnny Ordóñez

Algo que me gusta del libro es que provee «tips de supervivencia» para evitar estos peligros. Para este caso: enfocarse en el comportamiento y en la adaptación; esto es centrarse en la generación de resultados desde una perspectiva de comportamiento. Enfocar el propósito, identificar problemáticas y contextos, la toma de decisiones apropiadas en base a hechos, generación de acciones coherentes.

No importa cuando se invierta en libros, entrenamientos, certificaciones, reuniones, etc.; todo es una pérdida si los equipos no adaptan su mindset, comportamientos y acciones consecuentemente. Si bien, el entrenamiento en las herramientas conlleva a su mejor uso, la clave es no perder de vista que el propósito es escalar la montaña, no sólo saber a hacer nudos. Así como los Líderes de Gran Altitud, los Agile Coaches deben tenerlo presente; sea fuerte y no se deje seducir :).

Gracias por leer.

Johnny

Referencias:

Escalando el Índice de Felicidad

Medir la felicidad es algo complicado. La felicidad es algo abstracto e íntimamente ligado al aspecto personal, es difícil establecer un valor determinístico que permita concluir «qué tan feliz» se siente alguien. La felicidad es una elección consciente más que una respuesta automática. Sin embargo, dentro de las técnicas aplicadas por los equipos ágiles, existen interesantes herramientas para obtener información relacionada al estado anímico de los equipos y su satisfacción en el contexto laboral. En este sentido, el Índice de Felicidad se concibe como una medida organizacional de la percepción de satisfacción y motivación de los equipos ágiles. 

¿Por qué medir la Felicidad?

«El Compromiso de los empleados es un imperativo de negocio; este es el eje fundamental entre la estrategia y los resultados de negocio.»

– Trends in Global Employee Engagement, 2013

1. Agile es acerca de personas

La Agilidad proviene de las personas, no de los frameworks (Scrum, SAFe o cualquiera). La Agilidad vive en los equipos y florece gracias a un entorno de confianza, transparencia y colaboración auténtica. El impacto de la motivación y la satisfacción de los empleados se ha venido estudiando con atención desde hace un tiempo. A continuación algunas cifras al respecto recopiladas por compañías como Gallup y otras:

Cifras sobre la Motivación en el trabajo

Cifras sobre el Impacto de la Felicidad en el Negocio.

La Felicidad es un asunto serio. Preocuparse por la motivación y el bienestar de las personas es un reflejo de la mentalidad ágil, de un nuevo estilo de gestión, de una práctica saludable y recomendable para Líderes de Servicio, Coaches, Managers, área de Talento Humano y otros.

2. Permite medir promesas de Adopción

En un proceso de transformación ágil en el que participé utilizando SAFe como framework referencial, uno de los desafíos al que nos enfrentamos fue el de cómo medir la «Promesa SAFe» expresada en el siguiente gráfico:

Promesa SAFe

Resultados de Negocio de SAFe – SAFe Foundations

SAFe ha podido obtener estos datos de sus varios casos de estudio documentados. Con relación al engagement de los empleados, sus cifras están alrededor del 10% de incremento. Las preguntas fueron: ¿y cómo lo midieron? ¿y cómo lo medimos nosotros?. El Happiness Index resultó una herramienta útil para este contexto. (Para los otros aspectos, espero publicar pronto algo que puede servir; tema de otro post.)

3. Información que permite enfocar acciones de mejora sobre los equipos

Información valiosa que le permite a Scrum Masters, Coaches y Managers; enfocar acciones sobre aquellos equipos que necesitan mayor atención y protección. Sirve para indagar sobre las causas de su estado anímico, conversar, identificar problemas y actuar en busca de mejorar el bienestar de los equipos.

Se me ocurren otras razones, pero quizás estas sean las más importantes.

Mecanismos para medir la Felicidad

He leído de varios; desde el uso de aplicaciones en nube, encuestas de Google Docs y hasta el conteo de pelotas de tenis; todas muy interesantes.

Mecanismos para medir la Felicidad

Algunos mecanismos para medir la Felicidad

Más que las herramientas, siempre me ha gustado que este tipo de actividades sean muy lúdicas  y divertidas; entonces me gustan más herramientas empleadas en Retrospectivas. Dos de las que más me gustaron fueron el Happiness Profit de mi gran amigo Hiroshi Hiromoto y la variación del Happiness Radar de mi otro amigo Paulo Caroli de su libro Fun Retrospectives.

Happines Profit y Happiness Radar

Happines Profit y Happiness Radar – Técnicas para Retrospectivas

Debido a la información relacionada a varios aspectos, el Happiness Radar fue la elección que tomamos junto al equipo de Scrum Masters. Lo personalizamos y aplicamos en cada retrospectiva para los equipos.

Happiness Radar - Evac 2

El Happiness Radar de la Retrospectiva de un Equipo

Equipos

Equipos en Retrospectiva – Happiness Radar

Escalando el Índice de la Felicidad

1. Recopilación de la Información

Nos pusimos a trabajar y ensayamos nuestro primer sprint con la nueva técnica. Luego de la recopilación en la herramienta física, cada Scrum Master la pasaba a un excel que diseñamos para este propósito, un archivo por equipo.

Radar de Felicidad por Equipo

Archivo de Registro del Radar de la Felicidad por Equipo

Cada archivo era subido a un repositorio de donde una macro en Excel leía la información y la consolidaba en un archivo que unificaba la información de todos los equipos. La periodicidad de medición fue de cada sprint (cada dos semanas). Teníamos que establecer un nivel de automatización para que el proceso sea repetible y que no se constituya una tarea que demande demasiado tiempo, volví a programar en macros después de muchos años 🙂

2. La fórmula

El Happiness Radar es un mecanismo de conteo, es decir simplemente cuenta la personas con un estado anímico sobre un aspecto particular. La idea fue obtener un indicador que represente de la mejor forma la sensación de todo el equipo. Entonces, me basé en la fórmula del Net Promoter Score, usada comúnmente para medir la satisfacción de Clientes sobre un servicio o producto.

Fórmula del índice de la Felicidad

Fórmula del Índice de la Felicidad

La escala es un rango de entre -1 a 1, cuyos valores representan: +1: Equipo Feliz, 0: Equipo Neutral, -1: Equipo Triste. Luego se podría profundizar los aspectos y su valoración.

3. Visualización y Publicación

Quería que estaba herramienta fuera vista y discutida a nivel Ejecutivo y compartida por toda la organización, entonces figuraba en mi mente la mejor forma de presentar esta información, que fuera dinámica, muy visual y al estilo de dashboard o Balance Scored Card y en lo posible vía web. Excel no me iba a ayudar mucho por lo que recordé esta fantástica herramienta (con versiones gratuitas) para la elaboración de vistas y análisis de datos: Tableau nos salvó; así que me puse a «monear» (término ecuatoriano que significa explorar algo sin tener la certeza de lo que realmente estás haciendo, hacer monadas).

La herramienta debería contestar varias preguntas:

  • ¿Cuál es el nivel de motivación general de la compañía?
  • ¿Cuál es el equipo más “feliz” o motivado?
  • ¿Cuál es el equipo más triste?
  • ¿Con qué aspecto están más descontentos?
  • ¿Cuál es la tendencia de la felicidad en el tiempo?
  • ¿Qué equipo o equipos necesitan mayor atención?

De esta forma, el diseño de vistas debería responder de forma rápida estas cuestiones. Luego de mucho café y varios tutoriales en línea, logré crear algo como esto:

Puede explorarlo en línea en este link.

4. El proceso resumido

A modo de referencia, el resumen del proceso en la siguiente imagen:

Proceso

Proceso de Consolidación y Publicación del Índice de la Felicidad

Analizando la Información

1. ¿Mayor Felicidad = Mayor productividad?

Al principio la iniciativa de medir la felicidad fue vista como algo muy romántico, muy abstracto. Obviamente no era muy común escuchar de esto y no se había intentando algo similar antes. Si bien es cierto, se tenía en mente como algo que permitía medir la «Promesa SAFe», el staff Ejecutivo no veía mucho valor…hasta que resaltamos lo que decían los estudios: «Un empleado feliz es más 31% productivo». Recuerdan las cifras de arriba. Veía como empezaba a brillar una luz en los ojos de algunas personas.

Nuestra hipótesis fue: «A mayor felicidad mayor productividad». Aunque productividad es un concepto que se presta a discusión, sobre todo hablando de Agilidad (quizás un término del siglo XX como bien lo dijera Ángel Medinilla) el reto ahora es expresar desempeño en términos de agilidad. Como eran equipos Scrum, la respuesta fue muy obvia: «Velocidad» (otro concepto discutible, pero se escapa a este post). Al inicio no me gustaba usar la Velocidad, pensaba en que se prestaría a comparación entre equipos, y más significativamente uno de los motivos fue que no hay homologación entre los puntos o velocidades de los equipos, es decir, cada equipo tiene su propia definición de qué es un punto y sus velocidades no son comparables. Una de las formas de lograr una comparación más homogénea fue utilizar la Velocidad promedio de todos los equipos.

De esta forma, contrastamos Felicidad vs. Velocidad. Recuerdo que moría de ansiedad por ver los datos, en verdad esperaba que se cumpliera la hipótesis. Pero, oh sorpresa!…no fue así. Encontramos que podíamos tener equipos tristes con mayor desempeño, y equipos felices con una entrega inferior. ¿Por qué? Me rompía la cabeza tratando de encontrar explicación. Investigué y me encontré con el trabajo del Dr. Charles Kerns, PhD por el 2008 y que despejó mi mente.

Lo más interesante fue la siguiente matriz:

Felicidad vs Desempeño

Matriz de Felicidad vs Desempeño – Dr. Charles Kerns, PhD

Cada cuadrante corresponde a un grupo que poseen sus propias características y lo más interesante, el autor propone acciones de mejora específicas para ayudar a los equipos en cualquiera de las categorías. Esto fue revelador para mí. Lo discutimos con los Scrum Masters y podíamos enfocar acciones de mejora más claras con los equipos. Compartimos los hallazgos con los managers y los invitamos a generar acciones en conjunto. Estábamos muy felices! La herramienta sirvió en ayudar al crecimiento y bienestar de los equipos. Esto destapó la creatividad de los Scrum Masters, surgieron nuevas técnicas de retrospectivas, más actividades lúdicas, campañas y actividades interesantes para lograr mayor motivación. Gracias equipo! (a Katty, Andrés, José Manuel, Polo, Luis, Ana María, Stephanie y Ximena).

Pensamientos finales

Aprendí mucho de implementar esta herramienta. Espero que este post le brinde la guía y motivación para emprender una iniciativa similar en su compañía, y que por favor me comente cómo le fue. Obviamente, fórmulas, visualización y demás pueden mejorarse; pero más allá de eso, mi mensaje final es que considere el aspecto de la Felicidad como algo importante, y realzar su enfoque hacia cuidar y cultivar le bienestar en sus equipos y su organización.

«Las empresas a menudo se olvidan de la cultura, y en última instancia, sufren por ello porque no se puede entregar un buen servicio con empleados infelices.”

– Tony Hsieh, CEO de Zappos

Gracias por leer.

Referencias

La evolución de SAFe (en imágenes)

Uno de los aspectos de SAFe que más me gustan es su naturaleza evolutiva. A través del feedback de empresas, consultores, comunidades y practicantes en general, el framework ha ido creciendo, adaptándose, mejorando; hasta consolidarse en la versión actual SAFe 4.0 for Lean Software and Systems Engineering.

Esto es bastante bueno, ya que Agile se trata de eso, adaptación continua en base al aprendizaje. Si bien es cierto, SAFe no es la bala de plata para todos los escenarios ni todas las compañías, a mi forma de ver SAFe brinda un robusto conjunto de valores, principios, patrones y prácticas para llevar agilidad a nivel empresarial, más allá del área de TI y del desarrollo de software. Es un gran inicio hacia buscar la Agilidad empresarial, y tal como lo mencionara Henrik Kniberg; SAFe es un framework en modo Shu.

He podido hacer un tracking de la vida de SAFe en el tiempo y encontré versiones de varios Big Pictures desde el 2008 y de la época en la que SAFe todavía no se llamaba SAFe; desde los antiguos posts de Dean Leafingwell hasta la versión actual:

El pase de diapositivas requiere JavaScript.

¿Qué es lo nuevo en SAFe 4.0?

El nuevo Big Picture de SAFe trae -además de un diseño más sobrio a través de un matizado de grises- novedades interesantes para el escalamiento de Agile. A continuación comento las cosas que más me llamaron la atención:

El nivel de Value Stream

level_choice_3-4-768x948

Diferencias entre SAFe 4.0 en 3 niveles y SAFe 4.0 en 4 niveles

Posiblemente lo que más resalta a la vista es la posibilidad de expandir a SAFe de 3 a 4 niveles. Esto tiene una connotación importante, SAFe 4.0 en 3 niveles está diseñado para Value Streams donde el número de personas puede llegar hasta cien; SAFe 4.0 en 4 niveles puede albergar a Value Streams por encima de cien personas y habilita la coordinación entre varios Value Streams de diferente naturaleza, donde no todos están destinados necesariamente a desarrollar software; sino también hardware, firmware, trabajo con proveedores, entre otros.

fig-3

El Nivel de Value Stream – SAFe 4.0

Este nivel es muy interesante, incluye un enfoque hacia pensar en Soluciones (Solution Intent y Solution Context), nuevo roles, un framework económico para la gobernabilidad, un trío interesante (Value Stream Engineer, Solution Architect y Solution Management), Arquitectura Ágil a nivel de Value Stream, entre otros. Este nivel fue heredado y adaptado desde SAFe for LSE.

Realce de los Fundamentos, Valores y Principios

Esta característica me encanta. En la base de la Big Picture y sobre el costado izquierdo, se hace énfasis en los Fundamentos, mindset y principios, y adicionalmente en el esquema de implementación de SAFe propuesto por los autores. El verdadero camino hacia la transformación ágil empresarial viene de la comprensión e interiorización de los valores y principios más que de la ejecución de las prácticas. SAFe es coherente con los principios ágiles y Lean; los principios del Flujo de Desarrollo de Productos de Don Reinertsen (Second Generation Lean Product Development) y patrones exitosos de transformación ágil como Comunidades de Prácticas y Líderes de Cambio (o coalición de Cambio).

figure-1-foundations-layer

Secciones de SAFe 4.0 enfocado a Valores, principios y prácticas

Por lo tanto, hacer un realce sobre estos elementos invita al lector a profundizar sobre las bases de SAFe más allá de lo detallado en el Big Picture; teniendo en cuenta que su comprensión permitirá adaptar el framework a su contexto y obtener los beneficios esperados.

Kanban en el nivel de Equipos

Heredado también de SAFe for LSE. SAFe brinda flexibilidad a los equipos ágiles de seleccionar el método que mejor se adapte a su contexto y a la naturaleza de su trabajo (entrega iterativa o flujo continuo de valor), y esto es correcto, pues no todo tiene que ser Scrum necesariamente. Sin embargo, los equipos Kanban (sobre todo aquellos enfocados en el desarrollo de productos) pueden tener la necesidad de integrarse a la cadencia a nivel de programa; significa que hay consideraciones a tener en cuenta para logrartrabajar en armonía con los equipos que no son Kanban.

fig-5

Nivel de Equipos en SAFe 4.0

Hay varios artículos de los SAFe practitioners acerca de la implementación de Kanban dentro de SAFe que vale la pena revisar. Personalmente, he visto muy interesantes los webinars de Allan Shalloway donde habla sobre SAFe Kanban y LeanBan.

Nuevos tipos de ítems en los backlogs

SAFe propone un nuevo modelo para la gestión de requerimientos, incorporando en los backlogs de los distintos niveles nuevos tipos de ítems. En el nivel de portafolio existe el Enabler Epic, que de la versión 3.0 se lo conocía como Architectural Epic. A nivel de Value Stream existen el Capability y Enabler. A nivel de Programa, Enabler (antes Technical Feature). A continuación un resumen del nuevo modelo:

figure-1-safe-requirements-model

Modelo de Requerimientos de SAFe 4.0

CapEx y OpEx

Esto sí que es interesante. SAFe trae a la mesa la discusión sobre la Capitalización de la inversión que realiza la organización en las iniciativas que buscan lograr los objetivos estratégicos. De esta forma, en la asignación del presupuesto a los Value Streams, SAFe invita al Program-Portfolio Management Team, Epics Owners y Value Stream Managers a pensar en la distribución de los gastos operativos y del propósito de inversión en varios rubros: I+D, software para Venta, software de uso interno, etc. Algo que me ha parecido muy interesante y que deseo ahondar es la discusión sobre la Capitalización de Puntos de Historia de Usuario.

A continuación coloco algunos links donde encontrarán más información junto con mi invitación a revisar más sobre SAFe.

Manténganse ágiles mis amigos. Gracias por leer.

Johnny

Referencias

Innovación en Escala: Articulando SAFe para la generación de innovación – Parte 2

En la primera parte de esta serie explicaba una forma de organizar varios elementos de SAFe que articulados apropiadamente pueden brindar un enfoque válido para la generación de innovación a nivel empresarial, cobijados por la adopción de una mentalidad de emprendimiento al estilo Lean StartUp.  De esta forma, el post anterior presentaba los siguientes pasos:

  1. Definir un Value Stream enfocado a la Innovación
  2. Asignar presupuesto al Value Stream de Innovación
  3. Crear Iniciativas de innovación como Épicas
  4. Presentar y  refinar la Épica

A este punto, ya se cuenta con una Épica analizada y refinada en función de las perspectivas de Deseabilidad / People (¿ésta iniciativa resuelve alguna necesidad de alguien?)Viabilidad / Business (¿es ésta iniciativa rentable para el negocio? ¿están dispuestos a pagar por esta solución?) y Factibilidad / Technology (¿es posible construirla con la tecnología existente? ¿debemos crear tecnología para consolidar esta idea?).

Roles SAFe y DT

Épica vista desde las perspectivas del Design Thinking

Como resultado de este análisis, contamos con una primera versión de su Modelo de Negocio (deseablemente en un Lienzo) y un Caso Ligero de Negocio propuesto por SAFe, que le añade a la Épica mayor perspectiva de negocio y es muy útil para el Portafolio. Puede ser algo como lo siguiente:

Ejemplo de un modelo de Negocio

Ejemplo de un Modelo de Negocio

Es importante resaltar que estos elementos representan el diseño del «primer experimento» a ejecutar; de tal forma, todos los elementos del lienzo son sólo hipótesis y el modelo de negocio completo estará en evolución a medida que vayamos recolectando aprendizaje validado, a través del feedback de nuestros Early-Adopters, descubriendo sus problemas y necesidades.

Evolución del Modelo de negocio

Evolución del Modelo de Negocio

Una vez que nuestra épica ha sido aprobada por el Program-Portfolio Management Team  y asignada al Agile Release Train dentro del Value Stream, lo siguiente que SAFe sugiere en su dinámica a nivel de Programa es trabajar en la Visión, el Roadmap del Producto y en el Backlog de Features, a través de varios roles propuestos en este nivel:

Dinámica Nivel de Programa

Visión, Roadmap y Program Backlog en SAFe

Pues NO!, no lo haga así. Sí bien esta dinámica sirve bastante bien para la creación productos en otro tipo de Value Streams donde las condiciones de entrega y cumplimiento son diferentes, desde mi punto de vista ésta perspectiva no refleja una visión de emprendimiento y generación de innovación. No puede establecer un roadmap y backlog de Features para crear una solución a una necesidad y a un usuario que todavía no conoce; hay que experimentar, hay que aprender.

Entonces, en lugar de la Visión enfóquese en descubrir patrones, problemas, necesidades y aprendizaje validado; puede plasmarlos en un Problem Statement que puede cambiar con el aprendizaje obtenido. En lugar de un Roadmap, no pierda de vista su Modelo de Negocio y su evolución; y  en lugar de un Backlog de Features cree varias Hipótesis de Cliente, del problema y de la solución o producto.

Plan-based Mindset vs Lean StartUp Mindset

Pensamiento basado en Planificación vs. Pensamiento Emprendedor (Lean StartUp)

Realice un «Taller de Empatía» (Empathy Workshop)

Para lograr dirigirse a los elementos de la derecha en el gráfico anterior, es necesario «empatizar». En este taller el equipo emprendendor (en el que ahora se convierte el equipo de Programa de SAFe: Epic Owner, Product Manager, System Architect, Product Owners, Teams y los demás) se reúnen para profundizar sobre varios de los elementos del modelo del negocio y darle rostro a los Clientes y Usuarios, generar hipótesis de problema y solución más enfocadas, y bosquejar capacidades e interacción. En otras palabras, aplicar los pasos del Design Thinking.

«Design Thinking es un proceso de innovación enfocado en personas que se nutre de herramientas de diseño para integrar las necesidades de los usuarios, las posibilidades de las tecnología y los requisitos para el éxito de un negocio.» – Tim Brown, Presidente y CEO de IDEO

La dinámica de este taller me emociona. En los talleres de Design Thinking que he facilitado he visto una integración poderosa de la capacidad creativa y de ideación de los participantes, pensamiento enfocado a personas y uso de técnicas del UX que generan una energía genial y entregables fantásticos. Hay muchas herramientas y técnicas que se pueden aplicar el proceso de DT, sin embargo me permito sugerir el siguiente toolkit al que se le puede añadir o quitar elementos. Aplicando este toolkit he realizado talleres en aproximadamente 2 horas con excelentes resultados (pero tómese su tiempo):

Design Thinking Toolkit

Toolkit ligero para un taller de Design Thinking por Johnny Ordóñez

En esta presentación puede profundizar sobre cada paso y las herramientas propuestas dentro de este, así como también algunas fotos de los equipos y su trabajo.

Reemplace sus Features por Hipótesis

En el primer post de esta serie hablaba de llamar Agile Innovation Lab en lugar de ART a los equipos dentro del Value Stream de Innovación; esto es porque me gusta imaginarlo como lugar donde se están corriendo experimentos para probar hipótesis a través del método científico:

Método Científico en Lean StartUp por Alex Cowan

Una hipótesis es una explicación propuesta para explicar un fenómeno. Es un supuesto sujeto a experimentación.  Cuando junto con su equipo, crearon su Modelo de Negocio, definieron algunas hipótesis que responden a varias de estas preguntas:

  • ¿Quién es tu Usuario y quién tu Cliente?
  • ¿Qué problemas tienen?
  • ¿Cómo tu producto encaja en su vida personal o laboral?
  • ¿Cómo y cuándo usarán tu producto?
  • ¿Quién pagará por tu producto?

Considere a éstas Hipótesis al nivel del modelo de negocio. A continuación se pueden establecer hipótesis a nivel de «capacidades» deseables de producto o solución; es decir, construir el producto correcto para la necesidad correcta. Josh Seiden propone aplicar el enfoque de experimentación al desarrollo de software creando así algo denominado Hypothesis-driven Development. Las hipótesis son mejores que los requerimientos en el contexto del emprendimiento donde existe gran incertidumbre. Los requerimientos o features son mejores en contextos donde los estándares son bien conocidos, existe mayor conocimiento del cliente/mercado y de cierta forma el dominio del problema es «estable». Por esta razón, no significa que la dinámica propuesta por SAFe: Visión -> Roadmap -> Features está mal, simplemente no la creo apropiada para equipos en un Value Stream de Emprendimiento e innovación.

«Necesitamos cuestionar el concepto de tener requisitos fijos para un producto o servicio. Los requisitos son valiosos cuando los equipos ejecutan una bien conocida o entendida fase de una iniciativa, y pueden aprovechar las prácticas bien conocidas para lograr el resultado. Sin embargo, cuando se está en una fase exploratoria, compleja e incierta se necesita hipótesis.» – Barry O’Reilly, Co-autor de Lean Enterprise: How High Performance Organization Innovation At Scale.

Siguiendo la plantilla de Josh Seiden, una hipótesis luce así:

Ejemplo de Hipótesis

Ejemplo de Hipótesis usando la Plantilla de Josh Seiden

Priorice las Hipótesis

Una de las confusiones comunes de los emprendedores a los que he tenido la oportunidad de hacer mentoring, es aquella de diferenciar ¿quién es el Usuario y quién el Cliente?. En ocasiones son los mismos, en otras no. Cliente es quién está dispuesto a pagar por tu producto o servicio en busca de resolver una necesidad real que posee él o ella mismo o un grupo. Usuario es quien estará interactuando directamente con el producto o servicio, quien tiene el problema. Una forma de priorizar las hipótesis es usar la siguiente matriz:

Priorización de Hipótesis

Matriz de Priorización de Hipótesis

Comience por ordenar desde la sección roja hacia la turquesa. Otra forma de hacerlo es la propuesta por Josh Seiden que enfoca el probar los supuestos más riesgosos primero, aquellos de las cuáles no tenemos información y que pueden tumbar el emprendimiento en caso de ser falsas:

Priorización por Josh Seiden

Matriz de priorización de supuestos por Josh Seiden

Ambos enfoques son totalmente válidos y pueden ser usados en función de la madurez de su modelo de negocio, si posee mucha incertidumbre sobre sus hipótesis de Cliente y de Problema, quizás el segundo sea mejor. Si su modelo ha madurado y ha logrado comprobar efectivamente el Cliente, el usuario, el problema y se dispone a probar la solución, posiblemente el primero sea mejor opción.

Desgloce su Hipótesis en Historias de Usuario

A este punto varios agilistas me han preguntado: ¿y dónde están las historias? Tranquilos, vienen a continuación. A pesar de que esto no es parte del enfoque de Hypothesis-driven Development, cuando combina Lean StartUp y Agile Development donde sus equipos usan Scrum por ejemplo, es necesario establecer alternativas sobre cómo comprobar las hipótesis que sacaremos al mercado. Las historias de usuario tienen como objetivo comprobar el supuesto de la hipótesis a través de capacidades más pequeñas que se implementarán en el producto. Si bien es cierto, las historias también pueden ser expresadas en formato de hipótesis en su nivel de granularidad; mi consejo es hacer una correlación y dejar las hipótesis  un poco más «grandes» y que los equipos puedan descomponerla en elementos más familiares como historias de usuario.

Historia de Usuario

Ejemplo de Historia de Usuario

En un equipo Scrum, el responsable de hacer esto es el Product Owner; si bien este rol puede existir, es preferible que todo el equipo emprendedor trabaje destilando alternativas de producto para probar las hipótesis. En algunos casos, no necesariamente significará crear software.

La matriz podría verse así:

Hipótesis e historias

Hipótesis e historias

No es necesario llenar todas las hipótesis con historias. Es mejor enfocarse en definir historias para aquellas de las hipótesis con mayor prioridad que se desee probar en el siguiente Producto Mínimo Viable o MVP. Crear historias no es suficiente, es necesario priorizarlas también. Hay muchos métodos de priorización de historias de usuario, para este contexto sugiero utilizar el Método de Análisis de Kano porque se enfoca en lograr aquella «calidad subjetiva» que va más allá del cumplimiento de features, me gusta la búsqueda de elementos «deleitadores», sorprendentes, «no esperados» que son más cercanos a definir una mejor experiencia de usuario, vital para los productos de emprendimiento. No quiere decir que las demás no sean útiles, pero tengo una predilección personal por Kano.

Kano

El Modelo Kano

De esta forma, se podrán agrupar las historias de usuario por Básicas, Lineales y Deleitadoras:

Aplicando Kano a las Historias

Aplicando el Modelo de Kano a las historias

Tentativamente, las franjas desde la roja hacia la turquesa nos indican la prioridad y el orden del backlog. Sin embargo, la linealidad puede ser contraproducente. En algunos equipos Scrum donde hemos usado esta técnica, existe la tendencia de seleccionar primero aquellas historias que son básicas, luego las lineales y por último las deleitadoras; con el objetivo de cumplir las características básicas del producto, aunque al principio no encante.

No me gusta mucho, no debes esperar al final para deleitar al usuario; me gustan más una secuencia que nace de navegar por todas los tipos de historia tratando de entregar en cada MVP un poco de todo, y deleitando también:

Línea curva

Secuencialidad en la toma de Historias

Okay, pienso que puedo cerrar aquí por el momento. En el siguiente post escribiré sobre la definición del MVP y la medición del aprendizaje validado.

Gracias por su feedback.

Johnny

 

Referencias

http://www.alexandercowan.com/creating-a-lean-startup-style-assumption-set/

http://barryoreilly.com/2013/10/21/how-to-implement-hypothesis-driven-development/

https://dzone.com/articles/hypothesis-driven-development

http://swombat.com/2011/1/7/how-to-evaluate-and-implement-startup-ideas-using-hypothesis-driven-development

http://www.hackerchick.com/2012/04/hypothesis-driven-development.html

http://scaledagileframework.com/program-backlog/

Innovación en Escala: Articulando SAFe para la generación de innovación – Parte 1

Hace unas semanas tuve la oportunidad de brindar una clase introductoria a SAFe gracias a la invitación de los amigos de DevAcademy (gracias a Lennon y al equipo, siempre es un gusto). Muchas buenas preguntas de los asistentes y de entre ellas una muy interesante de parte de un gran amigo agilista, Pablo Lischinski, que quedó en mi mente y que me animó a escribir este post. La pregunta fue: «¿Y cómo se maneja la innovación dentro de SAFe?».

En  ese momento recordé que recientemente la casa de los valores de SAFe fue actualizada incorporando un pilar importante: Innovación.

 

Me permito realizar una traducción del texto en la columna para profundizar:

Pilar 3. Innovación:

  • Los «productores» innovan, los Clientes validan
  • «Sal de la oficina»
  • Proporcionar el tiempo y espacio para la creatividad
  • Aplicar la contabilidad de la innovación
  • Pivotar sin misericordia o culpa

Estos ítems representan la interpretación de SAFe a los principios del método The Lean StartUp. Mi respuesta estuvo enfocada en esta dirección y sobre cómo utilizar los recursos de SAFe para articular la generación de innovación en forma de productos o servicios. Sin embargo, pienso que innovación es algo que va un poco más de la aplicación de un método -y hablando sobre cómo aplicarlo en SAFe- siento que vale la pena ahondar.

Innovación es un mindset

Innovation ProcessPodemos encontrar muchas definiciones de innovación, todas interesantes y muy válidas. En lo relacionado a software, normalmente se conceptualiza como la capacidad de crear productos o servicios disruptivos (o agregar features), capaces de deleitar a los Clientes y abrir los mercados, dando la posibilidad a mejor posicionamiento estratégico e incremento en ventas y mayores ingresos como consecuencia. Esto está muy bien, sin embargo innovar va más allá.

Innovamos en todo. Todo el trabajo que se realiza relacionado al desarrollo de software está basado en innovación y el mismo la fomenta. Innovamos cuando escribimos código para resolver un problema, cuando usamos las herramientas para construir un proceso automatizado, cuando adaptamos y mejoramos el proceso, y en general cuando diseñamos formas para trabajar mejor y generar mayor valor. La innovación ocurre siempre y en muchos niveles, y debe ser concebida como un valor empresarial; como una mentalidad compartida y por ende un elemento clave en la cultura organizacional.

Innovación es algo más que simplemente crear productos innovadores, algo más que un proceso o método; conciba innovación como un mindset.

Articulando la generación de innovación en SAFe

Entrando en materia, deseo resaltar varios elementos en SAFe que articulados apropiadamente pueden brindar un enfoque hacia la generación de innovación a nivel empresarial.

Disclaimer: Esto no es una guía, método o proceso. Simplemente es resaltar elementos dentro de un framework que conceptualmente juntos pueden brindar una dinámica de creación de valor en base a experimentos desde una perspectiva empresarial.

Defina un Value Stream enfocado a la Innovación

Muchas compañías destinan parte de su presupuesto a actividades relacionadas a la innovación. Normalmente en grandes empresas existen las áreas de I+D o Investigación Avanzada. Este presupuesto se destina a dar vida a iniciativas que con una respuesta positiva del mercado pueden generar valor para la organización. Esta dinámica tiene cabida en SAFe y el punto de inicio es el Nivel de Portafolio.

El Nivel de Portafolio de SAFe centraliza la visión estratégica de la organización discutida y plasmada a través de Iniciativas de Negocio y Arquitectura Empresarial denominadas Épicas. La inversión en innovación es una decisión estratégica que busca cumplir una visión corporativa más alta. A este nivel se definen los Value Streams, que son la forma principal usada en SAFe para representar la entrega de valor (un concepto muy Lean).

Imagine que un Value Stream es una tubería por la cual la organización entrega productos y servicios hacia el mercado, y se recibe de regreso Valor para la organización representado por ejemplo: incremento en ventas, posicionamiento, reconocimiento de marca, etc. Más en la práctica, los Values Streams pueden definirse como líneas o frentes de negocio sobres los cuales se diversifica la generación y entrega de valor. Definir un Value Stream es una mezcla de arte y ciencia que implica conocimiento de la compañía y del mercado.

Traditional Value Stream

Representación SAFe de un Value Stream

De esta forma, lo primero en habilitar para la generación de Innovación como estrategia empresarial en SAFe, es contar con un Value Stream relacionado a Innovación, con un nombre que haga relevancia a aquello. Ahora deténgase a pensar por un minuto en lo siguiente: ¿Quiénes son los Clientes de este Value Stream dedicado a la Innovación? ¿nuestra empresa? ¿nuestros Clientes existentes? ¿nuevos Clientes? Son nuestros Early Adopters; aquellos visionarios quienes se atreven a adoptar un producto o tecnología novedosos y están dispuestos a pagar para  solventar una necesidad o problema que poseen. A mi me gustan estos cinco tips sobre cómo identificar sus Early Adopters.

Innovation Value Stream

Value Stream enfocado en Innovación y Emprendimiento

Asigne el Presupuesto al Value Stream de Innovación

Básicamente es la respuesta a ¿cuánto vamos a destinar este año para innovación? Cada Value Stream tiene asignado un presupuesto, y todo el presupuesto de la organización repartido en Value Streams se gestiona dinámicamente en el tiempo, lo que SAFe denomina Lean-Agile Budgeting. Es decir, el presupuesto asignado puede ser revisado y ajustado para dar vida a nuevas iniciativas que según el criterio del Program-Portfolio Management Team pueden ser oportunidades con mayores probabilidades de obtener mayor valor para la empresa en un momento determinado.

El presupuesto asignado sirve para financiar uno o varios Trenes de Entrega Ágil o ARTs (Agile Release Trains). Más que financiar proyectos, SAFe propone el financiamiento de Trenes Ágiles quienes son los responsables de implementar las Épicas. SAFe sugiere que el tamaño de un ART va de entre 50 a 125 personas. Posiblemente en compañías realmente grandes exista grupos de este tamaño dedicados a I+D o relacionados; sin embargo, no toda organización puede hacer esto por lo que el número de personas puede ser menor a 50. En lugar de ART, a mi me gusta concebirlo como un «laboratorio», algo como un Agile Innovation Lab; en lugar donde se están corriendo experimentos para probar modelos de negocio (no es que quiera inventarme más términos, pero suena bonito 🙂 ).

Iniciativas de innovación como Épicas

Dentro de la compañía en la que trabajo hay personas que constantemente están mirando el mercado, las tendencias en tecnología y lo que está sucediendo relacionado al giro de negocio. Estas personas pueden ser designadas formalmente para aquello (por ejemplo si son Analistas dentro de la organización o Investigadores ) o simplemente cualquier miembro dentro de la compañía. SAFe habilita a que cualquier persona en la empresa pueda convertirse en un Epic Owner y presentar una iniciativa al equipo de Portafolio; yo lo llamo: «Nadar en el estanque de Tiburones.» :). Imagine que Usted es un emprendedor que tiene una gran idea y está buscando financiamiento para lanzar su proyecto, se pone en frente de los inversionistas y comienza a «vender» su idea.

SHARK TANK - Mark Cuban, Daymond John, Barbara Corcoran, Kevin O'Leary, Robert Herjavec and Lori Greiner are

SHARK TANK – Mark Cuban, Daymond John, Barbara Corcoran, Kevin O’Leary, Robert Herjavec and Lori Greiner are «Sharks» on ABC’s «Shark Tank.» (ABC/ADAM TAYLOR)

En esta dinámica, la Épica es presentada y revisada por todo el equipo (de tiburones), se resuelven dudas relacionadas, se conversa sobre los beneficios y el potencial de la iniciativa, para luego ser votada; simplemente levantando la mano de aquellas personas que consideran que se debe invertir en la iniciativa, el voto de confianza. Si su «tiburonez» es bueno («Tiburonez»: lenguaje que se habla dentro del estanque: valor, dinero, beneficios, margen, etc.) y se decide continuar, se determinará qué Tema Estratégico es apalancado por la Épica y a qué Value Stream pertenece, en este caso, al Value Stream enfocado a Innovación.

Tip: Si va a nadar en el estanque de tiburones, entonces hable buen «tiburonez»: muestre un buen modelo de negocio.

La idea por sí misma no deja de ser sólo eso, una idea. Recuerde que está frente al estanque y no puede llegar únicamente diciendo: «Hagamos esta aplicación móvil, será bueno para la compañía». Para ayudar a fluir su «tiburonez» trabaje y presente un modelo de negocio convincente, y para esto puede apoyarse en varios «lienzos» para plasmar sus -hasta ahora- hipótesis correspondientes al Cliente (Early Adopters), el Problema, y su solución (en esta presentación, encontrará algunos de los lienzos más populares).

Personalmente me gusta el Javelin Experiment Board, porque su diseño hace que la definición de hipótesis sea más sencilla y concreta (un post-it) y como los demás, habilita una excelente comprensión visual.

Javelin Experiment Board

Trate de que no enfocarse en crear un lienzo o modelo perfecto. Tome en cuenta que todo estará sujeto a validación, incluyendo sus Early Adopters. Trabaje con su equipo para darle forma y sentido de negocio. No dude incorporar su lienzo al Caso de Negocio Ligero propuesto por SAFe para la presentación de Épicas

Todo puede pasar, pero asumamos que incorporando estos elementos y luego de sus sus 15-20 minutos de presentación ha ganado la confianza del estanque y aprobaron su épica. ¡Felicitaciones! Pero el proceso no termina allí, acaba de comenzar.  La Épica debe atravesar un Flujo Kanban donde se refina y está sujeta a las restricciones WIP de la compañía (relacionadas a Presupuesto y Capacidad Organizacional para Ejecución). Así es, normalmente las compañías poseen un presupuesto acotado. Para el siguiente paso del flujo deberá refinar su épica.

Epic Kanban Flow - SAFe

Flujo Kanban de una Épica propuesto por SAFe http://scaledagileframework.com/business-epic-kanban/

Refine su Épica

Luego de su primera victoria al salir vivo del estanque, es momento de brindar mayor detalle a su iniciativa, de refinarla; y esto no lo hace solo. En este punto me gusta mirar a una Épica desde las tres dimensiones tomadas de Discover to Deliver de Ellen Gottesdiener y Mary Gorman : Cliente, Negocio, Tecnología.

 

Customer, Businnes, Technology

Perspectivas de Discover to Deliver de Ellen Gottesdiner y Mary Groman

Es perfectamente coherente. No sólo hay que concebir ideas pensando únicamente en las necesidades potenciales del Cliente, también deben representar un negocio rentable para la compañía y debe poder hacerse con la tecnología existente.

Estas dimensiones se ven mucho más claras desde la perspectiva del Design Thinking y del Human-centered Design, donde las intersecciones de las dimensiones sugieren varios tipos de innovación:

design-thinking-962x1024

Dimensiones del Design Thinking

Nuevamente, enfocarse en:

  • Deseabilidad: ¿Esta iniciativa resuelve alguna necesidad de alguien? ¿Quiénes son? ¿Están dispuestos a pagar? ¿Es una propuesta totalmente nueva en el marcado?
  • Viabilidad: ¿Cuál es el beneficio para la compañía: incremento en ventas, posicionamiento? ¿Cuál es el margen potencial? ¿Podremos sostener su operación en el tiempo? ¿Cuál es el esquema de monetización?
  • Factibilidad: ¿Se puede lograr con la tecnología existente? ¿Cuáles son los desafíos técnicos o tecnológicos que presenta? ¿Poseemos los skills y  las herramientas para hacerlo?  ¿Cuáles son las limitaciones arquitectónicas?

Para cada dimensión puedo sugerir roles SAFe que apoyen en el refinamiento de la Épica desde cada perspectiva:

Roles SAFe y DT

Dimensiones del Design Thinking y Roles SAFe

Por ahora pienso que puedo cerrar aquí. En la segunda parte de este artículo comentaré sobre la visión del producto, el roadpmap y el backlog de Features.

Como siempre, gracias por leer y por su feedback.

Johnny

Referencias

http://scaledagileframework.com/lean/

http://theleanstartup.com/

https://www.rallydev.com/toolkits/enterprise-lean-startup

http://es.slideshare.net/jezhumble/applying-the-lean-startup-model-to-the-enterprise

http://www.infoq.com/news/2013/10/apply-lean-startup-enterprises

http://www.slideshare.net/JohnnyDark/lean-start-up-y-scrum-como-crear-productos-que-los-clientes-quieren-pagar

http://www.amazon.es/Lean-Enterprise-Performance-Organizations-Innovate/dp/1449368425

http://saiframeworkbalancer-762644628.us-east-1.elb.amazonaws.com/epics/

http://www.scaledagileframework.com/value-streams/

http://javiermegias.com/blog/2012/12/early-adopters-clave-nuevo-modelo-de-negocio-curva-adopcion-tecnologia/

http://innokabi.com/early-adopters-5-claves-para-detectar-a-tus-primeros-clientes/

http://www.scaledagileframework.com/budgets/

http://scaledagileframework.com/agile-release-train/

http://www.discovertodeliver.com/

http://designthinking.ideo.com/

¿Qué tan «Ágil» es SAFe, LeSS o DAD?

rlp-rackets-top A medida que SAFe, LeSS, DAD y otros frameworks ganan popularidad, aumenta también el debate acerca del «nivel de agilidad» y la adherencia hacia los principios ágiles de éstos. Decenas de posts circulan en la red y cada framework con sus adeptos. Pero antes de compartir mi opinión permítame contarle algo: soy un fan del Tenis; es mi deporte favorito. Lo practico desde chico, disfruto al jugar y en serio me esfuerzo para mejorar (porque en verdad me falta mucho 🙂 ).

Como todos los fans del tenis tengo varios jugadores favoritos, pero el mejor para mí, sin duda: Roger Federer. Rebosante de talento, dueño de un revés formidable y un estilo elegante. Fuerte concentración y su típica habilidad para leer al contrincante, adaptar su juego y ganar. Un maestro. Roger-Federer (Recortado)La herramienta principal de un tenista es su raqueta. Cada tenista usa la marca y el modelo de su preferencia, la que considera que se adapta mejor a su juego. Evalúa el tamaño, peso, tensión, diseño, etc. La de Roger es Wilson, y hay muchas marcas en el mercado. Raquetas Ahora pregunto:

  • ¿Cuál es el nivel de «tenis-ibilidad» de su raqueta?
  • ¿Qué tan «tenística» es la raqueta marca Wilson?.
  • ¿Es la raqueta la que permite que Roger gane?

Sin la necesidad de ser conocedores del tenis, Usted estimada amiga o amigo lector estará de acuerdo conmigo en que no es la marca de la raqueta la que hace que Roger Federer gane. Es más, la raqueta es lo de menos. Les aseguro que si le damos una raqueta de otra marca a Roger, seguiría jugando brillantemente (aunque podría tomarle un tiempo adaptarse). Cuando en varios posts leo a las comunidades debatir sobre que SAFe no es ágil, que LeSS es súper ágil, que DAD es medio ágil y muchos otros comentarios; sólo leo discusiones sobre raquetas. Sí, pueden ser ejercicios mentales interesantes, de hecho he entablado varias discusiones desde el punto de vista conceptual; pero al final de cuentas NO IMPORTA.

En serio, Usted piensa que Roger Federer se reúne con Rafa Nadal y se ponen a discutir: «mira, el nivel de «tenis-ibilidad» de tu raqueta no es bueno porque le falta esto, entonces tú no eres tenístico». Vamos, claro que no. Son discusiones inútiles. Están discutiendo de herramientas. Puede ser entretenido y aboga a nuestro mindset de ingenieros, muy analíticos tratando de descifrar el punto y la coma; pero de frente al mundo real y a los resultados esperados de la organización, no aportan o muy poco.

Por favor, no dogmatismos

Lo peor que puede pasar es encerrarnos en enfoques puristas. «Pero mira, si el que vela por el Producto no se llama Product Owner, entonces eso no es Scrum», «Que si no hay iteraciones no es ágil». Personalmente critico a aquellos agilistas que desde sus oficinas súper bonitas y abiertas al estilo Google, con mesas de ping pong y en zandalias, van a otra organización donde ven la cosa diferente y dicen: «Ah, es que Ustedes no son ágiles porque no tienen StandUps y no son tan cool como nosotros». Hay una parte del Manifiesto Ágil de la que muchos agilistas se han olvidado:

Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia como ayudando a otros. – agilemanifesto.org

Ayudando a otros. Esas compañías «no ágiles» representan más del 90% de las compañías de desarrollo de software (al menos en Ecuador); son a aquellas a las que debemos ayudar. Es allá a dónde debemos llevar agilismo, ayudar a esas personas a mejorar su forma de trabajo, a construir mejor software y hacer una diferencia en la industria. Ahora, también podemos quedarnos en la comodidad del palco de comentaristas y discutir sobre raquetas todo el día. Seleccionar la mejor raqueta no es el propósito Raquetas con nombres ¿Es Wilson mejor que Babolat? ¿Es Head más tenística que Prince? QUÉ IMPORTA!. El propósito no es adoptar una raqueta. El propósito no es adoptar un framework. El propósito es dar lo mejor en el juego siguiendo los principios del buen tenis. El propósito es ganar. No se trata simplemente de adoptar más prácticas XP, iteraciones y microservices por todos lados, ahora todos hacemos Scrum y ya somos ágiles. Llevamos las prácticas a la PMO, Marketing y otras áreas y listo, agilísimos!. No se trata simplemente de llevar agilismo más allá del área de TI (aunque esta sea una consecuencia); se trata de ir hacia la Agilidad Empresarial; desde mi punto de vista en dos sentidos: agilidad del negocio y nuevo mindset organizacional. Agilidad del negocio responde a aspectos:

  • Estamos mejoramos la Calidad de nuestros productos o servicios, de tal forma que con el menor re-trabajo estamos aumentando la satisfacción de nuestros Clientes y mejorando las ventas?.
  • Estamos mejorando nuestro Time to Market, de tal forma que entregamos valor al mercado y nuestros Clientes de forma temprana, lo que permite un ROI temprano y mejorar nuestro flujo de caja?.
  • Estamos mejorando nuestra Predictibilidad de tal forma que somos mejores en Venta y Delivery con menores tiempos de espera?
  • Estamos reduciendo desperdicios de tal forma que podemos re-enfocar nuestros recursos económicos en innovación u otras áreas de la compañía?

Nuevo mindset organizacional responde a:

  • Estamos mejoramos la Calidad de vida de nuestros colaboradores de tal forma que recomendarían a sus amigos a venir acá?
  • Estamos mejorando la Carrera profesional de nuestros colaboradores de tal forma que sienten que trabajan por un propósito y creciendo cada vez más?
  • Estamos mejorando la Calidad de nuestro Liderazgo de tal forma que fomentamos y habilitamos a nuestra gente a desatar su talento?
  • Estamos cuidando nuestros Valores y Cultura organizacional de tal forma que nos preocupamos en cuidarla y actuamos de forma coherente con los principios Lean y Agile?

Este es el propósito. Si Usted está pensando en transformar su compañía, prepárese para responder a estas preguntas (sobretodo las del primer bloque 🙂 ). Frente a los resultados el framework es irrelevante. Ganar el juego depende de ti.

La actitud y tu pensamiento son más importantes que cualquier metodología. – Masa Maeda

Imagine que va presenciar un partido de Roger y quiere saber si podría ganar el juego. Entonces Usted hace un análisis de los jugadores, revisa las estadísticas en las últimas temporadas, su desempeño en el tipo de cancha, los partidos recientes, lesiones, etc. ¿Usted podría predecir que Roger ganará el partido?. Difícil verdad. ¿Pero si está usando raquetas Wilson, eso debe servir? 😀 Para nada; ya vimos que la raqueta es lo de menos, no es relevante. No se trata del framework o herramienta que use.

En un partido de tenis hay decenas de factores por las que podría darse un resultado: las condiciones climatológicas, el estado de ánimo de los jugadores, el nivel de confianza, su entrenamiento, su comprensión del partido, el buen uso de la raqueta (sin importar la marca que haya seleccionado) y muchos más. Ahora; Usted desea adoptar, transformar o escalar ágil en su organización. ¿Su éxito depende del framework que use? Difícil saberlo. Dependerá de las innumerables de condiciones de su entorno. No es sencillo. Dependerá de su comprensión y entendimiento de los principios ágiles, del nivel de comprensión de su organización y los drivers de su negocio, del buen uso de las herramientas que seleccione (cualquiera de ellas), de su ánimo y del equipo de cambio que le acompaña, y del liderazgo y cultura de la compañía y muchos más. El éxito depende de Usted. El nivel de agilidad depende de Usted.

Si actualmente está evaluando frameworks para escalamiento de Ágil, le recomiendo no se estrese por encontrar el mejor de todos o el más ágil. Si le recomiendo leer casos de estudio y estar sintonizado a personas que lo estén usando desde la práctica, en las trincheras (nada de ejercicios conceptuales o puristas), hágales preguntas sobre las cosas que le pueden ayudar y obtenga sus propias conclusiones. Si no lo ha intentado aún, le invito también a jugar tenis. Y cuando vaya a elegir su raqueta, no se estrese mucho por escoger la mejor o la que posee mayor nivel de «tenis-ibilidad». Recuerde, ganar el partido depende de Usted; y quien mejor para inspirarse que el propio Roger:

Buen partido!

SAFe con esteroides, o SAFe for Lean System Engineering

Todavía no termino de comprender SAFe y ya se viene SAFe LSE. – Johnny

El equipo de Scaled Agile Inc., liderado por Dean Leffingwell y un grupo de contribuidores estrella -Harry Koehnemann, Alex Yakyma, and Inbar Oren– acaba de lanzar al público la primera versión de un nuevo framework empresarial denominado Scaled Agile Framework for Lean System Engineering o SAFe LSE; un marco de trabajo para la coordinación, desarrollo, integración y entrega de grandes -pero realmente grandes- sistemas a gran escala. Éste es un trabajo en progreso, y ha venido evolucionando desde Septiembre del 2014 a través de varios posts de los autores, que he estado siguiendo por su fuerte enfoque Lean y porque soy muy curioso; realmente me llamaba la atención al estar estudiando y aplicando SAFe. Okay, revisemos un poco.

¿Qué es SAFe LSE?

En una entrevista reciente, Dean Leffingwell comentó acerca de SAFe LSE:

SAFe está diseñado para soluciones de software a gran escala —soluciones de bancarias, financieras, seguros, ISVs, etc.— pero si usted está construyendo un satélite, donde tiene el satélite en sí, la estación de tierra, la granja web de alimentación de datos de usuarios, entonces esto es realmente un sistema de sistemas, y usted debe entender cómo los sub-sistemas se construyen e interactúan.

– Fuente: Interview with Dean Leffingwell

Interesante, un satélite; de verdad!?. Obviamente la visión dentro de SAFe LSE es más amplia. Un enfoque sobre el alineamiento del talento y esfuerzo de varios equipos en la construcción, integración e interacción de sub-sistemas para lograr construir a su vez un sistema, un propósito más grande. Lo interesante, es lo que los sub-sistemas no necesariamente son soluciones de software; sino también hardware / componentes electrónicos, productos de ingeniería mecánica o industriales, automotrices, de defensa, domótica, etc. Formalmente, SAFE LSE es:

Un marco de trabajo libre y público que brinda un conjunto comprensivo de valores, principios y prácticas para que los constructores de sistemas puedan apoyarse en la construcción de sistemas intensivos, complejos y de gran escala (a menudo llamados Cyber-physical systems) en una forma Lean y Ágil.

– Fuente: SAFE LSE Public Preview Unveiled

Al igual de SAFe, SAFe LSE se basa en un marco filosófico de principios:

Captura de pantalla 2015-03-17 a las 10.36.14 a.m.Fuente: SAFe for Lean Systems Engineering Manifesto

El Big Picture de SAFe LSE

Otro de los elementos que SAFe LSE hereda de SAFe, es el Big Picture. Como siempre repito, este artefacto es un «gol de chilena». Al igual que el acostumbrado Big Picture, es interactivo y al dar clic en cada item se mostrará información detallada de los conceptos, principios y del entendimiento del ítem para el framework. Al ser una primera versión, todavía se está creando contenido para el detalle de cada aspecto (no es tan rico como el contenido de SAFe) pero la información existente y el mismo big picture nos permiten tener una idea general de la estructura del framework y su propósito. Les invito a revisarlo aquí: SAFe LSE - Big Picture

– Fuente: SAFe LSE – Big Picture

¿Cuál es el propósito de SAFe LSE?

SAFe LSE está enfocado a los constructores de grandes sistemas cuyas soluciones comprenden la sincronización de varias otras soluciones (sub-sistemas) de distinta naturaleza para lograr un propósito a nivel sistémico; mucho más grande. Cada sub-sistema es una solución con su propia naturaleza, complejidad y desafíos. El propósito de SAFe LSE es brindar guía, prácticas y elementos basados en Agile, Lean, System Thinking para la construcción de sistemas interconectados a gran escala y que van más allá del desarrollo de software. No es una locura. SAFe LSE nace básicamente de la necesidad de aplicar SAFe a iniciativas de grandes entidades, entre ellas agencias del Gobierno de EEUU: Comercio, Justicia, DHS, NGA, Navy y la NASA. Estas organizaciones están explorando y usando SAFe para llevar sus iniciativas en una forma ágil. Hay experiencias documentadas acerca de este uso.

¿Cuál es la diferencia con SAFe?

Personalmente, pienso que SAFe está enfocado al desarrollo de soluciones de software a gran escala. SAFe LSE no sólo se enfoca en software; sino también en hardware, productos de ingeniería y los mencionados anteriormente. Todo bajo un enfoque holístico y sistémico de alinear y coordinar a varios equipos en la construcción de ecosistemas interactivos de sub-sistemas. Hay una aspecto particular que me llama la atención y es la incorporación de proveedores trabajando bajo la misma filosofía. Esto responde a una de las inquietudes más comunes de las empresas que trabajan bajo prácticas de agilismo, y es cómo hacer que nuestros proveedores se unan en este paradigma y trabajen bajo el mismo enfoque. Al parecer, SAFe LSE promete guías en este sentido. Hay que seguir revisando.

¿Qué esperar del nuevo framework?

Evolución constante. Muy característico de las propuestas de Dean Leffingwell y de Scaled Agile Inc. Aumento de popularidad en industrias especializadas: manufacturas, automotrices, hardware y componentes, sistemas que integren varios tipos de productos entre software, hardware, robótica, etc.; pero a gran escala. Por lo que serán ciertas organizaciones que lo adopten bajo esta visión sistémica integral y en iniciativas de varios años. Actualmente Scaled Agile Academy va a dictar el primer curso de SAFe LSE y las entradas se han agotado. Esto sin duda aporta al conocimiento y popularidad del framework. Sin embargo, no creo que veamos muchas implementaciones de SAFe LSE en Latinoamérica en el corto o mediano plazo; partiendo de la premisa de que no contamos con iniciativas tan estructuradas y definidas de interacción de sub-sistemas a mega o gran escala. No construimos muchos satélites. A diferencia de SAFe -en donde pienso que existirá un interés bastante alto en Latam y varias iniciativas de adopción a finales de 2015 y todo el 2016- SAFe LSE será una iniciativa que se comenzará a evaluar tras el conocimiento y mayor conciencia de SAFe y del mismo agilismo. A pesar del interés y conocimiento creciente en la región, todavía la ola Agile/Lean está madurando. Esto implica la comprensión del paradigma por el Top/Senior Management sobre los valores y principios ágiles, plasmados en la re-estructuración de esquemas compatibles de contratación para el desarrollo de software, redefinición de modelos de fábricas de software (muy popular en Latam), nuevos esquemas de management, acompañamiento calificado en adopción y transformación Agile/Lean, más profesionales entrenados, entre otros. Bueno, no soy futurólogo y no pretendo serlo; así que puedo equivocarme. Veamos.

Pensamientos finales

En este momento sólo estoy mirando este framework con ojos de curioso. Obviamente no tengo experiencia real en su aplicación y si Usted lo lee ambos conoceremos lo mismo. Sin embargo, su revisión me parece un ejercicio intelectual interesante, tratando de comprender desde el punto de vista de agilismo y de un involucrado en el desarrollo de software, el alineamiento con los principios Lean y Agile llevados a esta escala y a esta naturaleza de productos. Mientras leía los posts iniciales al respecto pensaba: «En realidad necesitamos algo -metodológicamente hablando- más grande para construir mega-productos de software? Cómo se conservan los principios Agile y Lean a esta escala? No es suficiente con SAFe?». Bueno, sigo profundizando y descifrando. A medida de aquello les compartiré mis apreciaciones. Gracias por leer. Saludos y por favor, manténganse Lean/Agile…en serio, muy Lean/Agile 🙂

Referencias

Los 3 Amigos en SAFe

friends

Un acercamiento al nivel de Programa de SAFe

En SAFe a nivel de programa existe un equipo denominado el Release Management Team. Este equipo tiene la responsabilidad principal lograr un incremento de sistema «decente» en cada iteración de la cadencia a nivel de programa, es decir; es encargado de subir funcionalidad en los vagones del Tren de Entrega Ágil (o Agile Release Train o ART) en cada salida. Un Agile Release Train tiene un significado dual en SAFe. Primero, un ART es para el nivel de programa lo que una iteración es para un equipo. Es una iteración para el programa. La analogía proviene de las cadencias de salidas de los trenes de una estación, las mismas que se definen en rangos uniformes de tiempo y de constante consecución. Cada ART produce un incremento de sistema; donde se integran todas las historias que componen las Features planificadas de todos los equipos que trabajan en el proyecto o proyectos que se terminaron y aceptaron por los Product Owners en la iteración que acaba de terminar. Al igual que a nivel de equipos, existe una “System Demo” donde los stakeholders, expertos de negocio, ejecutivos y Clientes entregan feedback sobre el producto; y lo más importante, determinan si este incremento de Programa o PI se convierte en un entregable hacia el mercado o hacia el Cliente, cumpliendo así con el concepto Desarrollo en Cadencia – Entrega en Demanda. El segundo significado es, el ART es un grupo de personas (típicamente de entre 50 a 125) trabajando de forma coordinada y alineada a los objetivos de negocio en un flujo constante de entrega de valor para un Value Stream definido para la organización. Significa, que un ART es un equipo de proyecto formado de varios equipos ágiles, equipos de operaciones y especialistas (por ejemplo UX y Arquitectura) y un equipo coordinador a nivel de programa llamado el Release Management Team (RTM) que mencionaba inicialmente.

Típicamente, los integrantes del RTM son: El Release Train Engineer, el conductor del tren (o cariñosamente llamado: «el chofer»);  la persona que lleva a los demás hacia cumplir los objetivos del release, o en palabras SAFe, encargado de llevar el tren a la siguiente estación a tiempo. Funge como el Chief Scrum Master (por lo que coordina estrechamente con todos los Scrum Masters del Tren), eliminando los impedimentos a nivel de programa, escalando y trasladando los impedimentos de los equipos hacia las áreas o roles de la organización, facilitando la sesión de Inspect & Adapt (o Retrospectiva a nivel de Programa). Coordinando, escuchando, guiando, facilitando; es el Scrum Master a nivel de Programa, pero tiene mucha responsabilidad en la ejecución. El Product Manager (o Product Managers, dependerá de cada tren), la persona o equipo quien sabe qué cosas van en los vagones; conocido también como el Chief Product Owner. Esta persona junto con los Product Owners, personas de negocio, Subject Matter Experts, Marketing o UX, conforman el Product Management Team. Al igual que un Product Owner, tiene la responsabilidad de destilar las Features, organizar al equipo para lograr estimaciones, priorizarlas, identificar dependencias y establecer el contenido de cada incremento de Programa o release. Naturalmente, trabaja estrechamente con los POs y posee una visión y conocimiento del negocio, más no técnico necesariamente. El Development Manager (últimamente un rol muy polémico en varias conversaciones vía Twitter que he tenido). Lejos de ser el Jefe de los desarrolladores como el nombre del rol podría intuitivamente sugerir, es la persona que se preocupa por el desarrollo personal y profesional de las personas en el tren. En el Big Picture de SAFe no aparece a simple vista este rol, pero ingresando por Lean & Agile Leaders podremos encontrar literatura sobre el rol. Alguna vez envíe un mensaje a las personas de Scaled Agile Inc. sugiriendo cambiar el nombre (algo como People Development Lead, People Lead o algo parecido), en verdad que se presta a mal interpretación y automáticamente puede calzar con roles existentes en una organización como Jefe de Desarrollo, Gerente de Operaciones o algo así. Independiente de esto, el Development Manager es un Agile Champion. Es una persona que conoce, vive y transpira los valores y principios del manifiesto ágil y del pensamiento Lean, pero con un enfoque muy fuerte hacia las personas, preocupado por su bienestar, porque tengan lo que requieren para realizar su trabajo, que el entorno sea favorable, que se sientan bien. Es quien se preocupa por el desarrollo personal, de carrera y profesional. Además, SAFe le da responsabilidad de velar por el desempeño de los equipos, manejar relaciones con personal externo involucrado en el proyecto, ayudar al RTE a eliminar impedimentos, eliminar distracciones y apoyar en el proceso de adopción ágil en la organización. El Business Owner, él o los responsables fiduciarios de los resultados de negocio (normalmente financieros) del valor entregado por el tren. Normalmente es un grupo formado por ejecutivos de áreas de negocio, marketing u otros. Son responsables del ROI de la operación y del aporte de valor al Value Stream y a la organización. Junto con el Product Manager establecen los objetivos del programa a cual se anclan las Features, para que posteriormente se descompongan objetivos de iteración para los equipos, a los cuales se anclarán las historias más adelante. Parte del RTM son también el System Architect, encargado(s) de proveer lineamiento sobre la visión técnica, tecnológica y arquitectónica de la solución, guiando a los equipos en el diseño e implementación del producto, ayudando a construir (o construyendo ellos mismos como un equipo ágil) la Pista arquitectónica o los «rieles» por donde circula el tren, etc.; UX Designers, que brindan guías y lineamientos para crear y mejorar la experiencia de los usuarios y del uso de buenas prácticas para el diseño de UI, dando feedback e investigando sobre el comportamiento de los usuarios; el System Team, el grupo que apoya a los equipos en tareas de operaciones, infraestructura, pruebas de sistema. El System Team tiene la responsabilidad de habilitar a los equipos que integren sus incrementos de producto, realizar pruebas de sistema end-to-end (Performance, Carga, Seguridad, Disponibilidad, etc.) y prepara el ambiente para la System Demo. Y otros miembros que cada tren decida integrar para ayudar a la ejecución y a la entrega de valor.

Este equipo es y debe comportarse como un equipo ágil. Vivir los principios de colaboración, transparencia y mejora continua. No necesariamente significa que debe contar con un tablero con sus actividades de cada iteración (aunque no es mala idea), deben contar con reuniones de coordinación frecuentes, monitorear constantemente el estado del release y del tren, ver si se está alineado con los objetivos de negocio y del Value Stream, comunicación cara a cara, sesiones de feedback, transparentar los problemas, analizarlos y atenderlos, alzar la mano cuando se identifican riesgos, coraje, respeto, colaboración.

La Tríada en el corazón de la colaboración ágil a nivel de programa

Al ser un equipo ágil, el RTM realmente no tiene la necesidad de contar con líderes o jefes; pero tiene el compromiso de trabajar colaborativa y proactivamente para lograr que unos de los valores de SAFe se cumpla: Ejecución del Programa; y mas allá, lograr una cultura de entrega de valor constante. De mi experiencia con SAFe a través de varios equipos y programas, he visto que -si bien es cierto la responsabilidad es de todo el tren y de la organización- existen tres roles a los que veo correr activamente, entendiendo los objetivos del negocio, priorizando el alcance, estableciendo las fechas de entregables en base al contrato, analizando los problemas, pegando el papelógrafo en la pared para la ejecución del Release Planning, agendando sesiones con los Stakeholders, pendiente de los equipos, etc. Los 3 amigos: Release Train Engineer, Product Manager y Development Manager. Tomen en cuenta que no necesariamente cada rol corresponde a una persona (pueden ser dos o más ejerciendo el mismo rol, en función del tamaño del ART) pero estos roles en mi punto de vista son vitales y complementarios entre sí.

Piensen un momento en que el propósito de SAFe es escalar los beneficios de Agile a través de principios, prácticas y roles. Si está escalando con sólo con Scrum, por ejemplo; con varios equipos y varios Product backlogs; podría contar con una configuración de Chief Product Owner como lo propone Roman Pichler. Podría contar también con un rol que está ayudando a escalar problemas hacia la organización y brindando guía sobre el proceso Scrum, un puente con el management y la organización; por ejemplo un Chief Scrum Master, quien asistiría y facilitaría la S2 (Scrum de Scrums) o incluso la S3 (Scrum of Scrums of Scrums). Y al tener muchos equipos trabajando juntos sobre la misma iniciativa, posiblemente requiera un rol que deba estar pendiente de proveerles lo que necesitan (organizacionalmente), de su moral para su día a día, de su expectivas, de su crecimiento personal y profesional. Independientemente de los nombres de los roles, yo identifico este patrón en SAFe. Básicamente, una configuración de escalamiento de las que ya hemos leído, y que podemos adaptar a cada contexto.

Pensamientos finales

Aunque SAFe proponer temas muy interesantes, en realidad es la recopilación de muchas de las estrategias, enfoques y prácticas exitosas para la aplicación de los principios del desarrollo ágil a escala organizacional. Nuevamente, SAFe es un framework (al igual de Scrum por ejemplo); lo que quiere decir que NO HAY RECETAS!; y que su aplicación será exitosa en función de su apropiada adaptación al contexto, al negocio y la organización, y sobretodo de los resultados de negocio que habilite; pero fundamentalmente, este o cualquier framework será exitoso en la medida en la que conserve, promulge y potencie los valores y principios del Agilismo.

Gracias por leer, abrazos ágiles!.

Johnny

 

Referencias

 

 

La Definición de «Ready» es tan importante como la Definición de «Done»

Ready

Usted no puede empujar a nadie a subir la escalera a menos que esté listo para subir por él mismo. – Andrew Carnegie

Uno de los conceptos más importantes y conocidos en el desarrollo de software ágil -utilizando varios sabores como Scrum y Kanban- es la Definición de «Hecho» (o Definition of Done, o DoD). La definición de Done es un acuerdo del equipo, y en muchas ocasiones de la organización. Mediante el criterio de Done se puede conocer cuando una Historia de Usuario se encuentra «Hecha» para ser presentada al Producto Owner o Stakeholders. Brinda una guía al equipo sobre las condiciones necesarias que debe cumplir una historia para ser decentemente terminada presentada durante o al final de la iteración. Es una herramienta que brinda transparencia y permite un entendimiento común de lo que significa “Hecho”.

Ya en la práctica, consiste en una especie de checklist que reúne los criterios acordados por el equipo al que se somete cada historia antes de ser colocada en la preciada columna de Done en el Taskboard. En muchos tableros he visto también la columna “Done Done!” o “Accepted” dando así dos niveles de aprobación de la historia de usuario, Done significa que cumple todos los criterios establecidos por el equipo que normalmente incluyen: el código en el repositorio, todas pruebas unitarias y de aceptación en verde, documentación si fuera necesario, integración en el ambiente de pruebas, revisión por el tester en el ambiente de pruebas, etc.; y «Done Done» o «Accepted» cuando ha sido revisada y “firmada” por el Product Owner.

Varios agilistas sugieren  lo mínimo que debe contener la definición de Done, y les dejo algunos artículos para su revisión un poco más abajo; sin embargo, quiero con este post hablar de otra definición quizás no tan conocida pero desde mi punto de vista bastante útil; la «Definición de Listo».

La Definición de «Ready» o DoR

Análoga a la Definición de «Hecho», la definición de «Listo» es un acuerdo entre del equipo, especialmente entre el Product Owner y el equipo de Desarrollo donde se colocan los criterios por las cuales una historia se encuentra lista para ser implementada dentro de un sprint. Básicamente, es un conjunto de condiciones -y un checklist también- a la cual se somete una historia para ser tomada en un Sprint Planning.

¿Por qué es importante?

Varias razones. Desde la práctica, una historia de usuario no está lista a la primera. El product Backlog es orgánico y necesita un tiempo de maduración. Significa que mientras el equipo de desarrollo está trabajando en las historias comprometidas en el Sprint Planning anterior,  el Product Owner está trabajando en refinar su backlog y poner a punto las historias para la siguiente y subsiguiente iteración (pienso que un buen PO prepara historias para un par de sprints adelante). Esto es, comprender el objetivo y el alcance funcional con los usuarios, expertos del dominio, UX designers, Product Managers; priorizar la historias usando técnicas apropiadas, descomponiendo historias en un tamaño apropiado para el equipo, estableciendo criterios de aceptación, identificando dependencias entre los items de su backlog y otros backlogs, colaborando con otros POs, entendiendo y revisando desafíos de arquitectura o técnicos con el arquitecto o Líder Técnico y trabajando junto con el equipo en el grooming del backlog, revisando y priorizando Bugs cuando aparecen. Así es, mucho trabajo para nuestro PO.

Bob Galen habla mucho del «Readiness Criteria» en varios artículos y en su libro Agile Reflections y sugiere una lista de Ready como la siguiente (a estos puntos les daré mi modificación desde mi criterio en paréntesis, pero la lista original la colocaré en las referencias):

  • Historias bien definidas y con al menos 5 criterios de aceptación (este valor es heurístico, igual se puede establecer un número máximo de criterios de aceptación);
  • Historias de un Tamaño apropiado, que entre dentro de un sprint (un tamaño adecuado con que el equipo se sienta cómodo y mejore su throughput, un buen tamaño que permita un mejor entendimiento, mejores criterios de aceptación, más fácil de probar, más fácil revisar, mejora la moral del equipo);
  • Que el equipo haya revisado las historias en una sesión de Grooming, donde se haya comprendido la naturaleza, el valor y desafíos técnicos;
  • De ser necesario, que la historia haya tenido un spike para explorar las implicaciones de diseño, arquitectónicas o tecnológicas (cuando el equipo no tiene mucha incertidumbre sobre lo que implica técnicamente la historia, es apropiado un spike; luego de eso la historia se puede revisar nuevamente, estimar y pasar a la columna de Ready);
  • Que la historia sea transversal, es decir que describa un comportamiento end-to-end (que sea “visible” para le negocio);
  • Que el equipo comprenda el enfoque para las pruebas tomando en cuenta aspectos funcionales y no funcionales;
  • Que se haya identificado dependencias con otras historias dentro del mismo backlog u otros backlogs a los que una historia pueda estar conectada;
  • Que la historia se alinee (y esté “enganchada”) a un objetivo u objetivos del sprint, que sean claramente visibles y demostrables.

Esta definición es bastante útil cuando tenemos a un PO que está desarrollando sus skills y su «olfato» para gestionar el trabajo para un equipo ágil. Ahora estoy trabajando con unos 29 equipos y un equipo de 14 POs; y acabamos de introducir esta práctica para lograr que las historias lleguen lo mejor trabajadas a los equipos; y estoy viendo varios beneficios de su aplicación (que espero que se sigan expandiendo):

  • Sprint plannings más rápidos;
  • Involucramiento y conocimiento temprano del equipo sobre los desafíos del siguiente sprint;
  • Gestión colaborativa del backlog;
  • Feedback temprano;
  • Levantamiento temprano de riesgos y necesidades (si se necesita del apoyo de un arquitecto, el SM ya lo puede buscar y planificar para el siguiente sprint);
  • Mayor conciencia del equipo sobre los objetivos de negocio y el alcance;
  • Ayuda al PO a comprender la visión sobre aspectos técnicos que le indica el equipo, y a sensar con qué tamaño de historias se sienten cómodos;
  • Historias mejor trabajadas en las cuales el equipo se siente parte y por ende mejora el compromiso.

Pensamientos finales

Pienso que el uso definiciones DoD y DoR claras y difundidas son herramientas muy útiles para la colaboración , claridad y “fluidez” de los equipos. Haga que el mismo equipo sea quienes revisen y definan estas definiciones, pero si están trabajando con varios equipos colaborando para construir juntos un “big working software” estas definiciones deben ser coherentes a través de todos lo grupos. Se puede crear comités y reuniones de trabajo para afinarlas. Igualmente, están sujetas a revisión y modificación tras cada iteración.

Coloque una columna “In Analysis” o “En Revisión” (o cualquier nombre, sea creativo) donde colocará aquellas historias sobre las que debe trabajar y refinar. Cuando estén listas y se cumpla con la DoR, agréguelas a la columna “Ready” o “Backlog” que son aquellas que se explicarán en el siguiente sprint planning.

Trabajar bajo estas definiciones brindará claridad y fluidez al trabajo de los equipos y aportarán a su crecimiento y madurez. Una vez lo que hagan, por favor compártanme sus experiencias.

Gracias, y que la agilidad esté con Ustedes.

Johnny

Referencias

http://guide.agilealliance.org/guide/definition-of-done.html

http://www.solutionsiq.com/what-is-the-definition-of-done-dod-in-agile/

https://www.scrum.org/Resources/Scrum-Glossary/Definition-of-Done

https://www.scrumalliance.org/community/articles/2008/september/definition-of-done-a-reference

http://www.allaboutagile.com/definition-of-done-10-point-checklist/

https://agilefaq.wordpress.com/2012/12/02/what-is-definition-of-ready/

http://www.batimes.com/robert-galen/user-stories-ready-set-go.html

Tiempo, Esfuerzo, Complejidad; ¿qué mismo es un Story Point?

«La propia palabra ‘estimación’ deja en claro que no calculamos un valor exacto,
determinístico. De hecho, toda estimación tiene supuestos, y estos supuestos suman
incertidumbres.» – Carlos Fontela, Estimaciones y Estadística, CyS Ingeniería de Software (2007)

Los más experimentados en agilismo leerán el título de este post y dirán: «¿y todavía hay dudas sobre esto?», posiblemente llevarán su cursor hacia la X y cerrarán la ventana. Pues, cuando comienzas una jornada de adopción hacia el mundo de Agile y Scrum con muchas personas que lo están aprendiendo y tratando de hacer match de los conceptos y prácticas sobre la forma tradicional, existen muchas preguntas que considerarías básicas; pero desde mi perspectiva son muy importantes, y pienso muy bien en las respuestas que daré. La importancia radica en que las prácticas, técnicas y artefactos del agilismo reflejan un mindset cuyos valores y principios deben ser comprendidos para encontrar el significado y el beneficio de usarlos; del por qué de la práctica, del por qué es diferente y en qué sentido.

La persona quien me hizo la pregunta había realizado la tarea y me muestra un artículo de Mike Cohn que titula: «Story Points are still about Effort». Y me escribe un párrafo por mail destacando lo que considera lo más relevante de la lectura:

«En el caso de los story points, se estima el esfuerzo (tiempo) para hacer una cosa – ese esfuerzo puede verse afectado por el riesgo, la incertidumbre o complejidad. Así que permítanme decir tan claramente como puedo: los story points son una estimación del esfuerzo, no de la complejidad.» – Mike Cohn

A línea seguida me escribe diciendo: «Tengo serias dudas de qué realmente es un story point: Complejidad o esfuerzo o tiempo?. Cuando le digo al Gerente de Proyecto que tenemos una desviación de 10 puntos frente a lo planeado, él me pregunta: con cuánta gente y en qué tiempo podemos resolverlo?. No sé qué responder.»

Adicional a esto, puedo agregarle un componente importante de mencionar. Siguiendo el marco de trabajo usado para la adopción en la compañía, en algún momento se dio por sentado en que existe una relación de conversión de Story Points a Horas, básicamente 1 Story Point = 1 día = 8 horas. De tal forma, aritméticamente se puede establecer una traducción que puede simplificar la comprensión de los story points y solucionar el problema mencionado.

Bueno, ahora me toca responder; y pensaba que hacer una precisiones primero.

1. Esfuerzo no es exactamente una unidad tiempo

El esfuerzo es una relación entre la cantidad de tiempo que requiere realizar una tarea en función de un número personas que la van a trabajar, y tradicionalmente se la expresa en personas-horas u horas-hombre o personas-mes. Básicamente, el esfuerzo relaciona tres dimensiones, tiempo, número de personas y la disponibilidad de éstas. De esta forma, si tradicionalmente estimamos una tarea que toma 8 horas para una persona (8 horas-hombre), y agregamos otra persona al 100% de disponibilidad, la tarea se terminaría en 4 horas aproximadamente. En los métodos tradicionales existen varias técnicas para la estimación de esfuerzo y a partir de este los costos: Cocomo, Puntos de función, Puntos de Casos de Uso, Putnam, Juicio experto, Delphi, etc. Todas expresan una relación entre tiempo y número de personas. Esfuerzo no significa tiempo a secas.

2. No existe una relación lineal de Story Points a Horas

Esto es algo que percibo ya en varias adopciones. Siento que existe una necesidad de poder expresar los puntos de historia en un lenguaje más conocido, como las horas-hombre. Algunas personas me dicen que es porque el Cliente así lo exige. En algunas ocasiones, he visto que se estiman las Features en Horas-Hombre y luego se las traduce a Story Points para establecer el número de equipos necesarios en base a su velocidad. Lo cierto es que esto no es posible hacerlo de esta forma y cualquier fórmula que nos creemos nunca nos dará una equivalencia real válida.

El problema con establecer los story points como tiempo es, que las personas tienden a generar una relación automática entre story points y horas; favoreciendo el pensar en horas gracias a la forma tradicional de estimación que nos solicitaban en el pasado. Por ejemplo, establezcamos una relación de 1 story point = 8 horas, como lo menciona SAFe. Cuando se le pide a un miembro del equipo estimar una historia, automáticamente está pensando en «¿cuánto tiempo me tardaré?», por varios factores agregan normalmente un buffer o colchón; y dicho valor lo dividen para hacer la equivalencia en puntos. «Okay, creo que me tardo 2 días, pero por si acaso voy a decir 3 días…en puntos significan 3 story points.».

Es volver a la pregunta: «¿cuánto te tardas en realizar esta tarea?», en lugar de «qué tan compleja consideras esta tarea con las condiciones dadas frente a esta otra historia de referencia ?».

Mike Cohn escribe un artículo posterior al mencionado arriba describiendo el problema y que básicamente al actuar así se pierden los beneficios de los story points, Don’t Equate Story Points to Hours:

«He sido bastante inflexible últimamente en que los puntos de historia son sobre el tiempo, específicamente esfuerzo. Pero eso no significa que usted debe decir algo así como: ‘Un punto de la historia = ocho horas.’ » – Mike Cohn

3. Un Story Point es una herramienta de Colaboración

Un Story Point es una medida que engloba: complejidad (inherente y accidental), tamaño, incertidumbre y habilidad/conocimiento sobre el problema planteado (ojo: tamaño y complejidad no son lo mismo).

En otras palabras un Story Point es la medida de esfuerzo mediante la cual un equipo evalúa la complejidad, el tamaño, el nivel de incertidumbre y el riesgo de realizar una historia en base a las destrezas, conocimiento y la información actual que poseen los miembros que conforman ese equipo, entendiendo que esfuerzo no es igual a tiempo.

Debido a la evaluación personal de estas dimensiones, una misma historia puede ser 1 punto para una persona y 8 para otra; un equipo experto trabajando mucho tiempo sobre el mismo módulo puede estimar una historia con un valor relativo menor que otro que nunca ha trabajado en ese módulo, y esto está bien. Los Story Points nos permiten realizar comparaciones relativas para establecer acuerdos sin importar el tiempo de resolución. La duración en tiempo para resolver la tarea es algo que se verá cuando se termine la tarea. Hay historias de 8 puntos que pueden ser terminadas en 2 días o en 4 días, pero para el equipo siguen siendo de 8 puntos, entonces no hay una relación lineal, la relación es una curva (como se muestra en este artículo http://www.targetprocess.com/articles/estimates-software-development.html).

Mi recomendación

En serio, no asocie un Story Point con tiempo. Puede generar disfunciones como: sobre-estimaciones, dificultad de llegar a consensos, dificultad en la comunicación del equipo, estimaciones basadas en tiempo como se hacía tradicionalmente, si lo toma María son 3 puntos, pero si lo toma Juan son 8, proliferación de fórmulas matemáticas de conversión, redondeos de los valores de la fórmula (ejemplo: si la fórmula nos entrega 8,6 el siguiente valor en Fibonacci es 13, entonces son 13 puntos), etc. 

Al usar el story point “puro”, le ayudamos a pensar al equipo en la dificultad propia del problema a resolver, más no en el tiempo ni en quien lo debe resolver. El nivel de incertidumbre estará dado por la misma escala de Fibonacci evitando sobre-estimación para cubrirse, esto a la larga cambia el mindset el equipo enfocándose en la cantidad de complejidad que pueden abarcar en un sprint. La idea es que el equipo vaya afinando sus estimaciones tras cada iteración, el mismo equipo junto trabajando sobre el mismo dominio durante un tiempo.

Referencias

Para más información les dejo estos links:

http://www.infoq.com/news/2009/09/story-points-versus-hours

https://agilefaq.wordpress.com/2007/11/13/what-is-a-story-point/

https://www.scrumalliance.org/community/spotlight/mike-cohn/june-2014/how-many-hours-is-a-story-point-worth

http://www.mountaingoatsoftware.com/blog/dont-equate-story-points-to-hours

http://www.targetprocess.com/articles/estimates-software-development.html

http://tracer.lcc.uma.es/problems/estimation/estimation.html

http://es.slideshare.net/mstabare/gestion-de-proyectos-estimacin-del-esfuerzo

http://scaledagileframework.com/iteration-planning/

http://www.slideshare.net/JohnnyDark/estimacin-gil-story-points-y-planning-poker