Software Development

3 razones del por qué sin Agile Testing no está siendo Agile

/ Johnny Ordóñez / 5 comentarios

3_stones_on_wood

Con relativa frecuencia -más de la que me gustaría- observo como las compañías y sus equipos adoptan Scrum para el desarrollo de software excluyendo deliberadamente a las personas de pruebas dentro de los equipos. Ellos consideran aún que el «desarrollo» significa únicamente codificación, manteniendo a las personas de testing alejadas del equipo, sin participar en las ceremonias e incluso en ubicaciones distantes físicamente. Cuando les pregunto sobre las pruebas funcionales durante el sprint, normalmente me responden: «Es que hacemos TDD…las pruebas funcionales las hacen al final y nos reportan los bugs en el sistema de tracking de incidencias.»

Lo que se puede observar es que se conserva el paradigma de que las pruebas es algo que viene después, realizado por un grupo de personas que está más allá, que es responsabilidad de alguien más; y no existe nada más alejado de la Agilidad verdadera.

Ahora quiero sintetizar en tres razones la importancia de comprender y asumir la disciplina de Testing y cómo ésta se evidencia en Agile:

1. Muchas de las promesas de Agile provienen del Agile Testing y de la automatización

El desarrollo ágil habla de mejorar el Time to Market, de aumentar la calidad, de incrementar la productividad y predictibilidad, y mejorar la motivación. Pues bien amigos, les aseguro: mucho de estas promesas provienen del ejercicio consciente del Agile Testing dentro de los equipos, más un nivel decente de automatización de pruebas e integración continua; todo esto en camino hacia habilitar Continuous Delivery. Agile no es magia, sigue siendo software que debe ser diseñado, construido y probado; el cambio está en el enfoque colaborativo y de integración en lapsos cortos a través de un equipo que combina sus disciplinas; es lo que marca la diferencia.

Imaginen el escenario donde se codifican historias en un sprint y luego al final le dan a un Tester o equipo de Testing que las prueben. Probablemente se encontrarán errores que serán reportados y corregidos por los equipos durante el sprint que corre. Al final del segundo sprint la persona o equipo de Testing deberá verificar la corrección de los bugs anteriores más la revisión de las historias del nuevo sprint; y no sólo eso; sino hacer una regresión de los flujos de negocio más importantes que involucra también historias del primer sprint. Ahora imaginen este ritmo para el tercer, cuarto, quinto sprint. Es una bola de nieve, y esto es grave. Las personas de Testing estarán con trabajo acumulado que supera su capacidad, la presión hace que reduzca el ámbito de pruebas y que minimice sus casos tomando en cuenta lo que considera más urgente y no lo más importante, la calidad de los casos de prueba disminuye, los managers estarán encima de ellos porque se evidenciará retrasos al no tener historias probadas; la motivación de este equipo estará por lo suelos. ¿Y los developers, pueden ayudar? No, están ocupados haciendo más historias 😦

Okay, esto no es Ágil. Son como cascaditas más pequeñas, nada cambió a excepción a que ahora generamos más código basura en sprints. Recuerdan aquel principio que dice:

«Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.»

– Principios del Desarrollo de Software Ágil, Manifiesto Ágil

2. Las personas de pruebas no son ciudadanos de segunda clase, son profesionales talentosos

Existe una percepción generalizada en la industria de que los testers son un tipo de profesionales de segunda clase, que no son tan importantes o necesarios o geniales como los desarrolladores, tienen salarios menores, hay una proporción mínima de testers en las empresas comparados con los desarrolladores, hay muy pocas capacitaciones -incluso en la Agilidad- y normalmente están en una sala aparte donde su trabajo se reduce a encontrar bugs. Recuerdo alguna vez que estaba con un equipo de gerentes trabajando en la planificación de un proyecto y decían: «Necesitamos aproximadamente unos 50 developers.», «Okay ¿y los testers?», «con dos juniors ya tenemos!». La disciplina en sí mismo está desvalorizada. Agile es contrario a todo esto, no puede seguir pasando. De hecho, cuando en las organizaciones veo este tipo de escenarios, son para mí olores de que su nivel de Agilidad está lejos de ser verdadero a pesar del uso de Scrum o cualquier framework.

Pues bien, la verdad es que sin nuestros amigos testers no podemos tener buen software ni software de valor. El testing de software es para mí una disciplina que requiere talento, preparación continua y un mindset diferente al de los desarrolladores para diseñar estrategias de mejor cobertura funcional y mejorar el diseño mismo del software. Las empresas y los equipos deben darse cuenta de lo trascendental de este rol.

3. Agile Testing es igual a colaboración

El Agile Testing es el pegamento entre las expectativas de negocio y la construcción. El tester es parte del equipo y es un puente de colaboración y comunicación entre el Product Owner, Stakeholders y developers más gente de operaciones, quienes codifican y mantienen los requerimientos para satisfacer esas necesidades.

Por ejemplo, el Tester trabaja junto con el PO y le apoya en:

  • Mejor comprensión de las necesidades
  • La preparación y revisión de historias
  • La definición de Criterios de Aceptación (a partir de los cuales se pueden generar Escenarios de Prueba)
  • Mejor entendimiento del Dominio de Negocio
  • Identificar dependencias entre Historias

El Tester trabaja junto con los Developers y les apoya en:

  • La definición estrategias de prueba para las historias
  • Apoya en la automatización de pruebas funcionales (ATDD)
  • Detecta y notifica bugs
  • Entrega feedback temprano de las historias
  • Sugiere mejoras funcionales y de usabilidad

Por su lado, el Tester trabaja en:

  • Preparación de la estrategia de pruebas del sprint
  • Preparación y mantenimiento del Ambiente de Pruebas
  • Preparación de Casos y Data de Pruebas de las historias del Sprint
  • Validación de “Done” de las Historias
  • Registro y notificación de Bugs
  • Aceptación de la Historia junto con el PO
  • Llevar las métricas de Calidad de Software

El Tester trabaja junto con otros Testers y equipo de operaciones en:

  • Diseñar y preparar la estrategia general de pruebas
  • Colaborar junto con los Stakeholders en las pruebas UAT
  • Identificar los escenarios y flujos de negocio más vitales
  • Difundir el Plan, Casos de Pruebas para Integración
  • Ayuda a conocer la salud del entregable
  • Identifica dependencias
  • Apoya en las pruebas de requerimientos No funcionales
  • Apoya en las pruebas de sistema end-to-end

Como pueden apreciar, son funcionales muy importantes.

Pensamientos finales

Nuevamente, Agile es más que adoptar y adaptar frameworks. Entiendo que existe un frenesí en la industria, pero sin una verdadera comprensión de los valores y principios detrás de las prácticas, sólo son cascarones. El Agile Tester es parte del Scrum y es el mejor amigo de los developers, se comporta como un compañero cuyo objetivo es ayudar a mejorar el software, dar feedback continuo y evitar a aparezcan errores en lugar de ser sólo un filtro para detectarlos, participa activamente en las ceremonias y es parte del éxito del equipo. En mi experiencia, es un rol vital y no puede existir agilidad sin este apoyo.

Gracias por leer y por compartir sus experiencias.

Johnny

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

/ Johnny Ordóñez / Deja un comentario

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

El Levantamiento de los Movimientos «#No»

/ Johnny Ordóñez / 1 comentario

NoMovements

No sé si soy yo, pero siento que en Latinoamérica existe un creciente interés acerca de algo que yo denomino, los «movimientos #No»: #NoEstimates, #NoBacklogs, #NoManagers; que ya tienen un rato dentro de la jerga agilista (yo me encontré con ellos hace unos años). En realidad pienso que es esto es bueno porque demuestra mayor exploración y, en términos generales, mejor entendimiento del pensamiento Lean; y quizás de una transición de enfoques de desarrollo iterativos incrementales (como Scrum) hacia otros donde se habla flujo de entrega de valor (como el método Kanban). Buenísimo!

Pero -desde mi punto de vista- hay que tener cuidado en no caer en enfoques puristas que pueden alejarnos de los beneficios que estos movimientos pueden brindarnos. Mi opinión a continuación:

#NoEstimates

“Una buena estimación es aquella que provee una visión de la realidad del proyecto suficientemente clara como para permitir a un equipo decidir correctamente cómo controlar el proyecto de modo tal de cumplir sus objetivos”. – Steve McConnell, Software Estimation: Demystifying the Black Art

Las estimaciones son inútiles, pero el proceso de estimación es valorable. El proceso de estimación es un proceso de conocimiento compartido, muy valioso para los equipos; no por el valor de estimación obtenido, sino por la discusión alrededor. Si las estimaciones y la dinámica aporta valor para su organización y a sus Clientes, úselos; recuerde también que tiene áreas Comerciales, maneja contratos y departamentos legales; estas cosas siguen existiendo en el mundo real. Si las estimaciones no le aportan valor, deséchelas; pero independientemente, revise su contexto y manténgase enfocado en la entrega de valor: hacia el Cliente y hacia la organización.

#NoBacklogs

«No hay nada derrochador sobre el concepto del backlog. Un backlog en sí mismo no es un desperdicio. Lo que importa es cómo las personas lo usan. Los trabajadores creativos necesitan herramientas para almacenar sus ideas y recordar sus opciones. Sólo de trabajadores de manufactura se debería esperar mantener su inventario bajo y sus máquinas limpias.» – Jurgen Appelo, Backlogs Are Not Waste

No a los backlogs estáticos, esos sí son desperdicio. No a backlogs de cientos de requerimientos que se levantan «up-front» y que cuyo valor se pudre en el tiempo. Si su backlog es un inventario entonces es un despercicio. Pero si su backlog está continuamente cambiando gracias al feedback de sus Clientes o del mercado, adaptándose a las necesidades, mutando continuamente para maximizar la entrega de valor, generando discusión y experimentos; esto es aprendizaje, respuesta al cambio. Sí a estos backlogs. Crear software no es igual al trabajo de manufactura.

#NoManagers

«Cuando la cultura de una organización es mala, no sólo es culpa de los managers. El Management de una organización es responsabilidad de todos. Un mejor management significa «enganchar» a la gente, mejorar el sistema entero e incrementar el valor hacia nuestros Clientes.» – Jurgen Appelo, Management 3.0 Workout

Managers no es igual a Management. El management en una organización -bueno o malo- no es sólo responsabilidad de los managers, es responsabilidad de todos. Es un sistema complejo donde se conjugan principios, comportamientos, reglas «no escritas», sistemas de recompensas, cultura, diseño organizacional y más. Ver a los managers como la causa de todo mal es sólo ver los árboles, no el bosque; no es sistémico. Sí a la descentralización de decisiones y a la autonomía en los equipos, pero esto no es igual a no tener managers.

Un nuevo movimiento #No

Por favor no interprete que trato de decir que estos movimientos son malos. Lo contrario, mi invitación es a explorarlos, comprenderlos y analizar su aplicabilidad en su contexto; si le aporta valor y le funciona, adelante! Al mismo tiempo, le invito también a no establecerse en una postura purista al respecto; lo que le funcionó a Usted para su contexto, puede que no aplique en otro.

Yo me atrevo a proponer un nuevo movimiento: #NoDogmas. Podemos sentarnos a discutir por horas sobre cuáles enfoques son conceptualmente mejores y cuáles no. En realidad no importa, todos pueden estar equivocados y algunos pueden servir para un contexto determinado; sólo se sabrá cuando se aplique; pero independientemente de todo, siento que encerrarse en enfoques puristas no es recomendable para las organizaciones y equipos en los que tratamos de llevar agilidad. Agilidad sobre debates metodológicos.

Como siempre, gracias por leer.

Johnny

SAFe con esteroides, o SAFe for Lean System Engineering

/ Johnny Ordóñez / 1 comentario

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

/ Johnny Ordóñez / 2 comentarios

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

 

 

El Product Owner debe ser un arquitecto?

/ Johnny Ordóñez / 1 comentario

La semana anterior conversaba acerca del tema a través de twitter  con un amigo agilista de Ecuador. Cuando él propuso esto, lo debatí fuertemente; ya que para este momento no concebía que un arquitecto de software pueda llevar la gran responsabilidad del PO. Mi temor estaba orientado a que podría dársele más énfasis a aspectos técnicos y tecnológicos que a satisfacer las necesidades funcionales y expectativas de negocio de nuestro cliente. Al final del día, no importa mucho si lo haces con .NET o Java, 3 capas o cliente-servidor, si el producto no es de calidad (según mi visión de calidad basado en el modelo Kano), sino representa utilidad para el negocio y las funciones diarias del cliente; sino deleita.

Durante esta semana (y mientras escribo este post) tuve la oportunidad de participar en un curso de arquitectura basado en la visión del IASA. He descubierto que estaba muy sesgado acerca del rol de un buen arquitecto de TI y un buen arquitecto de software, comprendiendo que un buen arquitecto buscar solucionar problemas de negocio apalancado en tecnología, algo fácil de decir pero muy complicado

Formando un equipo ágil

/ Johnny Ordóñez / Deja un comentario

Luego de recibir un curso, charla o seminario de Agile o Scrum se genera un gran entusiasmo al conocer una nueva forma de crear software, un conjunto de nuevos principios y sobretodo al descubrir los muchos beneficios que la agilidad brinda sobre el enfoque de desarrollo tradicional. La energía crece al saber que Agile o Scrum no son las metodologías o frameworks de moda, sino más bien un movimiento que está empujando a la industria del software y a otras hacia nuevas direcciones en las que se garantiza productos de calidad y clientes deleitados (algunas estadísticas #mce_temp_url#).

Como resultado del estusiasmo, al siguiente día la oficina luce paredes llenas de post-its, varios StoryBoards y compañeros de pie ensayando su primer Stand-Up meeting. Toda esta buena energía es positiva, sin embargo debe ser correctamente canalizada. En el proceso de adopción de Agile muchas organizaciones comienzan velozmente al aplicar las prácticas sin tomar mucha atención en la interiorización de los valores Agile. Generalmente todos desean aplicar Scrum pero no se tiene un inicio claro del qué vamos a hacer, porqué o para quién.

En mi experiencia al comenzar a plasmar los conceptos de la agilidad, he resumido unos pocos pasos que están dando buenos resultados en el proceso de adopción en la empresa en la que trabajo y que deseo compartir:

1. Full Empowerment: contar con el respaldo total por parte de la organización (o instancias superiores) acerca del proceso de adopción de una práctica ágil como Scrum para el desarrollo; la organización debe estar convencida de los beneficios que brindará sobre la manera de crear software. Agile implica muchos cambios a nivel cultural y de procesos que deben ser auspiciados por la empresa. Este respaldo es importante ya que brindará autonomía al equipo y le dará espacios transparentes para la toma de decisiones. La difusión del inicio del proceso como un programa piloto es parte de este punto. Si Usted es un emprededor ágil debe comenzar a «vender» y generar confianza en los directivos de su organización.

2. Invitación a participar a las personas que lo deseen: Identificar e invitar a las personas que posean los perfiles apropiados, talentos y habilidades pero por sobretodo, estén con muchas ganas y entusiasmo de comenzar con Agile. Que su forma de pensar y de actuar sea de cierta forma coherente con los valores y principios de la agilidad y que estén deseosos de aprender y mejorar. A mi forma de pensar, pesan más las ganas, la capacidad de aprender, desaprender y reaprender por sobre el badaje técnico que se pueda tener.

 3. Identidad: Cuando propuse este punto como parte del inicio de un equipo, muchos me preguntaron…para qué?. El sentido de identidad va más allá de un nombre para el equipo, consiste en brindar un sentido de pertenencia, unión y colaboración entre las personas que conforman el equipo. Identidad la entiendo como la definición de un nombre, valores, principios y acuerdos que constituyen la cultura del equipo y rigen su comportamiento. La siguiente pregunta fue: pero…no son los mismos valores y principios del Agile Manifesto??. Mi respuesta fue: hagamos de este equipo nuestro equipo y que represente lo que somos y lo que hacemos. La definición de la identidad es la primera reunión del nuevo equipo -nada formal-, donde todos aportan efusivamente y se llega a los primeros acuerdos. Cada nuevo miembro del equipo debe estar de acuerdo y comprometerse con lo acordado.

24012012885

 

13012012842

4. Lenguaje común: consiste en el manejo homogéneo de conceptos, términos y prácticas -tanto técnicas, tecnológicas, procedimentales y de agilidad- de los miembros del equipo; no necesariamente con gran nivel de profundidad o un manejo experto de cada tema; pero si una visión y comprensión de los conceptos que usará el equipo. Durante mi experiencia en este punto, se organizaron varias charlas informarles entre los miembros del equipo (no más de 40 minutos entre contenido y preguntas), en donde todos propusimos temas en los cuales se tenía ciertas dudas, deficiencias o simplemente temas que se querían conocer; además de los que todos considerábamos importantes antes de iniciar. Fue un proceso de aprendizaje bastante satisfactorio, ya que los que más conocían acerca de algo compartían su experiencia con los demás miembros. Se hicieron breves Coding-Dojos y talleres altamente participativos. En muchas literaturas se denomina a este punto como Iteración 0, sin embargo pienso que más que una evaluación de nuestra habilidad con herramientas y tecnologías, la formación de un Lenguaje común es un elemento que involucra otros aspectos y que no necesariamente están dentro del contexto de adquirir o conocer nuestro Velocity.

2301201287723012012878

5. Envisionamiento del Producto: Okay, es aquí donde comenzamos a vivir más intesamente la agilidad. Básicamente la definición del qué vamos a hacer, el porqué y para quién se realiza en este punto. Qué es lo que vamos a lograr como equipo. Es la definición del norte acerca del producto que se desea construir. Como todos sabemos, en Scrum es el Product Owner quién acerca la idea al DevTeam a través del Product Backlog. Es vital contar un PO con las características adecuadas y el conocimiento que dirigirá el esfuerzo del equipo de desarrollo. El PO motiva al equipo. Su Product Backlog lo reta constantemente y le inyecta dinamismo. Si no se cuenta con un PO lo más recomendable para mí es emprender un proyecto al interior de la misma empresa, alguna solución que agregue valor en donde nuestros compañeros más conocedores del negocio al cual se quiere ayudar, nos entregue su enfoque de producto sin ser necesariamente un PO, podemos involucrarlos y juntos con el equipo emprender un proceso de discovering y crear una visión de producto compartida, en la cual poco a poco se vayan abordando prácticas como el Visual story Mapping con la participación y el conocimiento de todos.

6. Requisitos Operacionales: consiste en la definición de aspectos importantes para el desempeño diario del equipo:

  • Common workspace: Importantísimo. un ambiente de trabajo que fomente la colaboración, comunicación y comodidad del equipo, facilite las Daily Meettings y otras reuniones, se puedan ubicar StoryBoards, etc.
  • PCs, networking, ambientes de desarrollo, pruebas de usuario o de review, servidor de integración continua, herramientas de colaboración y comunicación.
  • DevOps: el primer acercamiento del equipo de infraestructura hacia la agilidad. El concepto de DevOps es acercar al equipo de desarrollo con el de infraestructura-operaciones de la compañía. Estos dos mundos que siempre han estado separados, ahora trabajan junto con el DevTeam para realizar una exitosa entrega continua. Las tareas de Configuration Management, Versionamiento y otras son manejadas en este contexto. Por lo general en equipos o empresas pequeñas estas tareas son manejadas por el mismo DevTeam, sin embargo cuando existen muchos proyectos o se requiere colocar entregables en ambientes de producción de ciertos clientes estas operaciones conjuntas son necesarias (hablaré más de DevOps en un siguiente post más adelante).

7. Y…creo que estamos listos para emprezar!!

Estos pasos no son una guía formal o rígida (tanto en el orden como en la forma de abordar cada punto). Crear un equipo ágil depende mucho del contexto de la empresa, las personas y de los productos a construir; pero espero que en un sentido general estos pasos sirvan de utilidad para aquellos que desean comenzar firmente el camino hacia la agilidad y hacia un crecimiento personal y profesional. Me gustaría conocer sus comentarios y/o sugerencias al respecto. No olvidemos que Agile involucra un aprendizaje continuo.

Muchos saludos.