jueves, febrero 04, 2016

Todos Terminarán Siendo Ágiles


Hace un tiempo he venido reflexionado junto con mi círculo de amigos de Ágiles Colombia, especialmente con Lucho Salazar (@luchosalazarc) y Leonardo Agudelo (@sweepnoise), sobre que pronto la industria en general, los monstruos de la tecnología, las certificaciones, etc, tenderán hacia el cambio Ágil (Agile) o incluirán en su estilo o títulos algo relacionado con esto (1).


Y el cambio será (esta siendo) relativamente natural y orgánico,  este cambio nace desde TI con:


y nuestro afán en dejar de fallar haciendo en software (pues desde TI, llevamos años y años fracasando y haciéndole perder dinero, tiempo y oportunidad a nuestros clientes, a nuestras empresas y tiempo valioso de familia o descanso a todos los que han (hemos) estado involucrados en proyectos de software) y comenzamos a enfocarnos diferente, a generar valor de forma distinta, a trabajar más en equipo y generar valor en periodos cortos, y este cambio ha hecho que alguien ajeno a TI, diga: "estos locos están haciendo las cosas distinto, por fin funcionan, que podemos aprender de ellos, yo quiero eso mismo para mí y mi equipo".

Pero ¿quién no desea ser exitoso en los proyectos que emprende y usar las técnicas y herramientas más apropiadas?

Y si yo desde otro enfoque, industria, mercado o empresa veo que otros lo están haciendo bien y les esta yendo bien, lo más obvio es que quiera copiar esa buena forma de trabajo y usarla en mi contexto (recordemos que la copia es una forma de innovación).

Ágil, no es sicorigido, es más emergente y orgánico (como lo expresaba arriba) y se va adaptando según se va comprendiendo y se va transformando la cultura.

Si observamos bien:

Entre muchos otros enfoques, vemos que esto no es una moda, que es un enfoque distinto para hacer las cosas y que llego para quedarse.

Yo doy la bienvenida a todos los que se quieran sumar a este esquema, más natural, humano, orgánico, adaptativo y retador de trabajo, enfocado en el trabajo de equipos autogestionados, dirigidos, con propósito, que transforman no solo a las empresas de TI, sino todos los nichos donde se encuentran.

Yo anhelo que hayan muchas empresas que se embarquen en este estilo de gestión y dar resultados más pronto que tarde, tanto por el beneficio de sus empleados como de esos mismos negocios (recordemos que en negocios quien no se adapta y evoluciona desaparece).

Pronto todos trabajaremos con porciones o la torta completa del enfoque ágil, y los beneficios totales o parciales que de este se deriven.

Yo por mi parte me sigo quedando con la parte DEL PRESENTE CONTINUO del Manifiesto Ágil, que reza:

Estamos descubriendo formas mejores de desarrollar
software generar Valor (2) tanto por nuestra propia experiencia como
ayudando a terceros.



Seguiré buscando formas mejores de generar valor, tanto para mi beneficio, los equipos de trabajo en los que participo, como para mis clientes.

Saludos ágiles

Jorge Abad.




Fuentes y aclaraciones:

  • (1) Acuérdense de mi, un día llegará que CMMi tendrá certificación AGILE
  • (2) Modificación que le observé Agustín Villena @agustinvillena
  • Management 3.0. Jurgen Appelo

sábado, enero 30, 2016

Acomodando o Forzando Scrum para Equipos de Testing


Hola a todos (hace tiempo no escribía, discúlpen lo perdido que he estado)

Hoy hablare un poco de como he visto que se hacen proyectos de testing bajo el marco de Scrum o al menos ser ayudados por el marco. Comencemos.


------

PROLOGO

La tradicional forma de ver el software en cascada entre empresas,  en donde:

La empresa “X” construye el software (entregándolo probado),
y la empresa “Y” lo prueba y certifica


Va seguir viva en nuestro entorno por un tiempo más y la causa raíz de esto es sin duda la desconfianza, pues ya sea por procedimiento, requerimientos corporativos de seguridad ponemos a un tercero a que pruebe, generando la calidad de la calidad.*

NUDO

Recordemos, “en Ágil la idea es hacer la menor cantidad de software con calidad que genere el mayor valor de negocio**”, pero muchas veces, debido a estos  esquemas de desconfianza “CASCADIZAMOS ÁGIL” y se cae en que:

  • un equipo hace desarrollo ágil cumpliendo su DEFINITION OF DONE
  •  y otro prueba el DONE del anterior, cayendo en la calidad de la calidad, el proceso y reproceso, y por ende el desperdicio

Bajo esta premisa el equipo adicional de testing – de la empresa “Y” –
dice: “yo voy a probar usando Scrum”


¡ ¡ ¡OMG!!!


Seamos claros, ese equipo usará del framework de Scrum para realizar la gestión del proyecto realizando:
  • Planeación
  • Ejecución
  • Revisión
  • y Retrospectiva
Pero bajo este esquema “LOS EQUIPOS DE TESTING QUE EMPLEAN EL PROCESO DE SCRUM PARA PROBAR, REALMENTE NO HACEN SCRUM” pues Scrum sirve para construir productos, y bajo este esquema solo lo estamos probando.

Pero a pesar de lo anterior, procedamos a homologar lenguaje que equivaldría en este esquema:
  • El Product Backlog es todo lo que hay que probar
    • Casos de uso
    • Historias de usuario
    • Requisitos no funcionales
  • El sprint backlog
    • Es lo que se selecciona a probar durante el ciclo
  • El team es un equipo de testing
  •  Product Owner y Scrum Master conservan sus definiciones.
Entonces cual es la DEFINITION OF DONE de un equipo de testing bajo estas características
  • Todos los casos de prueba de la HU o del CU diseñados
  • Las evidencias asociadas a casos fallidos o exitosos registradas en el repositorio
  • Reporte de incidencias encontradas actualizado.
Y la DEFINITION OF READY:
  • Casos de uso o historias de usuario desarrollados y congelados en un ambiente para testing
  • Documentación asociada congelada.

No dudo que este esquema sea efectivo, lo he visto:
  • Potencializa más el trabajo en equipo, pero no se nota la fortaleza e interacción de un equipo multidisciplinario que construye software.
  • Se mejora la predictibilidad de diseño y ejecución de casos de pruebas

Conclusión

En la medida que hagamos mejor ágil, un mejor DONE (procesos y practicas técnicas que aseguren los productos) estos esquemas comenzarán a desaparecer, al igual que los testers evolucionarán a testers que no solo hacen pruebas funcionales, sino que automatizan, realizan pruebas no funcionales y hacen parte crucial del equipo de desarrollo.



Notas

*si vamos a ser sensatos esto tiene todo el sentido en proyectos donde a la empresa “X” construía el software haciendo cascada, generando grandes cantidades de software, que  talvez entregado a la fuerza y en consecuencia, obligando al cliente a contratar a un tercero que le certifique que lo que le entregaron muchos meses después si sirve.
**y saliendo a producción lo antes posible, para generar el mayor RETORNO DE INVERSION (ROI)

martes, diciembre 15, 2015

Buenas y Malas Prácticas en el Review / Demo de Scrum

o El Review no es una reunión de Testing




Hola a todos

En la medida que se va implantando Scrum, sprint tras sprint, el Scrum Master debe enfocarse cada vez más en que cada una de las reuniones de Scrum y la ejecución del mismo conserven el espíritu del agilismo: dar valor al negocio, con la menor cantidad de software posible a pequeños incrementos.

En este ejercicio se debe velar por que no se caigan en malas prácticas durante las reuniones de Scrum, en este post me enfocaré en la reunión del Review / Revisión / Demostración / Demo (la verdad me gusta más la palabra Demo) la cual esta definida según la guía como:

"Una reunión informal, no una reunión de seguimiento, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación de información y fomentar la colaboración."(1)



A continuación comparto unos tips y malas prácticas que he observado en los Demos:
  • Malas prácticas
    • Creer que la reunión de Demo es una reunión de User Acceptance Testing (UAT), revisando paso por paso los casos de prueba: 
      • Esto hace que la reunión se vuelva extensa, que no se cumpla el timebox (2), además ¿Cuándo se logra probar en una reunión de 2 horas el software que se produjo en 2 semanas?, implicando que se desconfía en el "Done" / "Terminado" que asegura el equipo y/o los testers encargados de realizar las pruebas.(3)
    • Realizar la Demo con capturas de pantalla (pantallazos) de los casos de prueba que lograron el Done durante el Sprint
      • La ventaja del Demo es esa, poder hacer una demo de lo que se hizo, y el hecho de presentar los pantallazos, no cumple con uno de los principios ágiles "software funcionando es la principal media de progreso". Es necesario poder navegar y "jugar" con el software durante la demo.
    • No invitar a Interesados / Stakeholders claves a la reunión
      • El Product Owner debe trabajar para que haya inspección y adaptación sobre el producto, de esta forma dentro de la reunión del review se brinda a stakeholders claves la posiblidad de realizar feedback sobre el producto y poder dar lineamientos sobre su progreso, el demo es el espacio para realizarlo, y no hacerlo en este tiempo es perder tiempo valioso.
  • Buenas prácticas
    • Preparar la Demo
      • El equipo debe preparar la demo y guardar un tiempo al final del sprint para preparar data a ser usada, ambientes, etc. en caso contrario el review puede llegar a ser fallido, o alguno de los ítems del incremento no funcionar correctamente y no darse por aprobado.
    • Cuidar el Timebox
      • El Scrum Master debe velar para que el timebox del la reunión se cumpla, proporcionando feedback oportuno a cualquiera de los asistentes cuando alguna solicitud vaya en contra del propósito de la reunión o el tiempo del a misma.
    • Realizar revisiones JIT (Just in Time / Justo a Tiempo)
      • Esta práctica consiste en que durante el Sprint el equipo cuando alcanza el Done de algún item del Sprint Backlog, lo presenta al Product Owner para recibir feedback, aceptación y/o rechazo del mismo, de forma que no se espera hasta el review, y de esta forma recibir feedback oportuno. 
      • Esta práctica tiene la ventaja de hacer un review (o demo) más exitoso y más liviano en el tiempo.

Hasta acá esta pequeña lista, espero sea de ayuda y provecho para los demos en sus equipos



Saludos ágiles

Jorge Abad



Referencias y Aclaraciones
(1) Guia de Scrum - scrumguides.org
(2) Timebox de las reuniones de Scrum - clic aquí -.
(3) Existen equipos que no tienen alguien destinado específicamente al testing y existen equipos en que sí, en general lo que hay que garantizar es que el equipo sea multifucional, no polivalente (cada persona sabe realizar bien todos los roles).

Ejemplos de Artefactos Empleados en Metodologías Ágiles / Scrum UNAB 2015-02

Hola a todos

Siempre he reconocido en los ejemplos el poder de ayudarnos a comprender mejor los conceptos.

Nuevamente les comparto el resultado del trabajo de la cátedra TÓPICOS TÉCNICOS  II, que impartí en la ESPECIALIZACIÓN EN TECNOLOGÍAS AVANZADAS PARA EL DESARROLLO DEL SOFTWARE, de la Universidad Autónoma de Bucaramanga (Colombia).

En esta materia vimos tanto el Agile Inception, el desarrollo y ejecución de un proyecto empleando Scrum, como la atención de un area de gestión de incidentes empleando Kanban (debo un post sobre este tema).

Los entregables desarrollados son:

  • Agile Inception
    • Mapa de Impacto (Impact Map)
    • Product Vision Board
      • Visión
      • Grupos de usuarios
      • Necesidades
      • Funcionalidades
      • Beneficios
    • Product Backlog  Board
      • Técnica Personas
      • Restricciones
        • Lo que no nos deja dormir (Riesgos)
        • Sería genial que pasara (Oportunidades)
        • Prioridades (alcance, tiempo, costo, calidad, usabilidad, adaptabilidad, seguridad, etc)
        • Incluido en el alcance
        • Fuera del alcance
      • Modelos /Diagramas
        • Despliegue
        • Procesos
        • Diagrama de contexto
        • Mockups
    • User Story Map / Construcción del Release Plan 
    • Calculo del tiempo y costo de la construcción del producto,  empleando una hoja de cálculo de mi autoría (clic aquí para acceder a la hoja de cálculo y su explicación)
    • Construcción del Product Backlog basado en requerimientos con historias de usuario
  • Simulación de Scrum
    • Simulación de tres sprints de scrum, durante una sesión de 4 horas, generando los siguientes entregables:
      • Historias de usuario
      • Bocetos asociados a las historias de usuario
      • Gráfica de Burndown de cada Sprint
      • Gráfica de Velocidad
      • Gráfica de Release Burn Up
      • Mejoras identificas cada sprint


En estos links encontrarán los cuatro proyectos con los entregables citados:

  • SerVIP -Sistema para la notificación oportuna de daño en los servicios públicos  link
  • Enjoytravel -Sistema planear un viaje empleando un vehículo propio- link

Espero los disfruten y les ayude en sus proyectos.

Saludos ágiles

Jorge Abad

sábado, diciembre 05, 2015

Ejemplo User Story Map - Solicitud de Crédito

Hola a todos

Les comparto este Mapa de Historias de Usuario - User Story Map, para un proceso de solicitud de crédito.

User Story Map - Sin Priorizar



User Story Map - Con Releases



Espero les sea útil.


Saludos Ágiles

Jorge Abad.





viernes, diciembre 04, 2015

Ejemplo Mapas de Impacto - Impact Map

Hola a todos

Les comparto dos mapas de impacto que elaboré en clase, bien recibido el feedback.

Mapa de Impacto - Reducción de tiempo de solicitud de Crédito

Mapa de Impacto - Reducción de accidentalidad


Saludos ágiles
Jorge Abad

lunes, noviembre 23, 2015

Product Owner - Interno o del Proveedor

Hola a todos, les comparto esta gráfica que desarrollé sobre  las ventajas y riesgos de tener Product Owner Interno o Externo, espero les sirva [1].

Saludos ágiles
Jorge Abad


Referencias
[1] Experiencia, y charlas de Ángel Medinilla @angel_m

domingo, noviembre 22, 2015

Un gran poder conlleva una gran responsabilidad. Una reflexión sobre la falsa concepción de autogestionado





"Un gran poder conlleva una gran responsabilidad", le decía el tío Ben a Spiderman, y la verdad, es de los primeros mensajes que se debe dar a un equipo cuando se les habla de autooganización

Muchos team members (miembros de equipo en Scrum) malinterpretan el término y lo consideran una declaración de anarquía que implica que ya no deben cumplir su contrato laboral, con expresiones como:




  • "Como soy autogestionado no tengo que avisar a nadie a que horas entro o salgo de trabajar", considerando que tienen una jornada laboral contratada de 8 ó 9 horas (según el contrato laboral (¡¡¡PLOP!!! - caso real -)
  • "Trabajaré haciendo lo que mejor pueda, aunque pueda dar más no lo voy a hacer"
  • "Como soy autogestionado, puedo dedicar todo el tiempo que desee a facebook o whatsapp"
  • "Salgo a hacer una vuelta y no tengo por que avisarle a nadie"
  • "Aunque todos llegan a las 8 am para el daily, la verdad  a mi eso no me aporta llegaré todos los días a las 9 am y no estaré en el daily por qué eso no me aporta" (¡¡¡RE_PLOP!!! - caso real -)
  • "Ya hice mi parte y la pasé al equipo de Quality Assurance"
  • Cuando salgo antes del horario de oficina sin importarme el compromiso del sprint por que soy "autogestionado"
  • Cuando inflo las estimaciones en el planning para trabajar con "muy buena holgura" 
  • etc.[1]


Mike Cohn (@mikewcohn) argumenta (clic aquí)
  • Autogestión no significa (clic aquí)
    • El equipo decide que objetivo alcanzar
    • o incluso quien es parte del equipo
  • Autogestión es:
    • acerca como el equipo determina como responder al ambiente (a los objetivos planteados)
    • y los líderes y gerentes influencian el ambiente
La autogestión es mas orientada a ser capaces de gestionar el trabajo en progreso y monitorear el progreso, y en un nivel superior cuando el equipo es autoorganizado (cuando el equipo es más maduro) ser capaces de diseñar el equipo y su contexto, como lo muestra la siguiente imagen:
tomada de[2]: 

Entre tantas cosas he descubierto que un equipo es autogestionado cuando

  • Son dueños del sprint backlog durante el sprint.
  • Deciden cual es la mejor estrategia para consumir el sprint backlog durante el sprint.
  • Honran los compromisos y la palabra dada en el planning  y utilizan el timebox del sprint lo más productivo posible, y en caso de que se termine el sprint backlog pedir al PO más ítemes
  • Si me comprometí con mi equipo a hacer una cantidad de puntos, a no dejar tirado a mi equipo con el compromiso
  • Dan visibilidad de los impedimentos
  • Ponen todo el empeño para que en la jornada laboral se cumpla el compromiso y en caso de observar que no se va a cumplir dar visibilidad de las razones que ocasionaron que no se cumpliera
  • Gestionan el progreso durante el sprint tanto en el kanban, burdown chart o cualquier herramienta de gestión y/o gestión visual
  • Sus team members cumplen con el contrato laboral (la verdad es lo mínimo, pero hay personas que es necesario explicárselo)

Y es allí donde el papel del Scrum Master toma importancia pues guía al equipo y a los respectivos team members a entender el concepto, a hacerles entender la responsabilidad que tienen y el poder que tienen en sus manos. De manera  que están cambiando el micro-seguimiento o RC [3], por la libertad de dar visibilidad del progreso y de potencializar la interacción con sus compañeros generando verdadero trabajo de equipo.

Yo creo en el agilismo, lo he visto funcionar, pero siempre que comienzo con un equipo scrum es de los primeros mensajes que doy, pues libertad no significa libertinaje, y agilismo no significa que no te enfoques responsable y maduramente en cumplir los compromisos que adquieres al principio de cada ciclo o sprint.


Termino como empecé, parafraseando un poco

"Team Member ser autogestionado es un gran poder, y un gran poder conlleva una gran responsabilidad"

Saludos ágiles

Jorge Abad



Referencias 
  1. Hay algunos pensamientos extractados en el hashtag de twitter #LesaAgilidad (sería genial que aportaras algunos que consideres)
  2. http://www.applitude.se/2011/05/self-organizing-teams-the-most-debated-agile-principle/
  3. RC: "Respiración en el Cuello" del gerente de proyecto, que por ejemplo pregunta cada hora, ¿cómo vas?



lunes, noviembre 16, 2015

Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización


Desde hace un tiempo vengo profundizando en cómo lograr la autoorganización en los equipos,  este tema me apasiona entenderlo e intriga de forma insistente a quienes pasan de la gestión tradicional (comando - control) a la agilidad, como lograr la autoorganización (la confianza, la inspección y adaptación). He escrito varios post con este tema de trasfondo:
  • Ejecutando proyectos con equipos autogestionados - clic aquí
  • ¿Y por qué dudamos de la auto-organización de los equipos? - clic aquí
  • Como Jugando Fútbol - Un Símil con Scrum - clic aquí
  • Cualquiera puede ser ágil / Cualquier equipo puede ser ágil - clic aquí
  • Más en el label Autoorganización- clic aquí

Y lo que quiero compartir hoy es, como un Scrum Master lleva al equipo a la autoorganización (algo comencé en este post - Comenzando con un equipo en Scrum: Parte 2 - Ciclo de vida de los equipos -) pues es allí donde toma valor la presencia de un Scrum Master como parte del equipo.

Coincido plenamente en el modelo propuesto Ángel Medinilla  @angel_m, para los pasos o edades que vive un Scrum Master, en el cual se pasa de "The Scrum Guy" hasta "Scrum Sensei"


Pero, aunque se alcance el estado de "The True Scrum Master" o "Scrum Sensei", es necesario considerar el liderazgo situacional (propuesto por Blanchard) cada que se inicia un nuevo team de Scrum.


Ese liderazgo situacional (o estilo de acompañar a un equipo Scrum por parte del Scrum Master) debe ser según el estado de madurez del equipo





*Etapas del equipo vs Tipo de Scrum Master Requerido (elaboración propia)
Etapa del equipo (Tuckman)
Tipo de Scrum Master Requerido

Scrum Dude / Scrum Guy
1. Formación ( Forming)
Scrum Mom
2. Conflicto (Storming)
True Scrum Master
3. Normalización (Norming),
True Scrum Master
4. Desempeño (Performing),
Scrum Sensei / True Scrum Master
5. Separación (Adjourning),
Scrum Sensei / True Scrum Master


Y ese estilo de acompañamiento que lo lleva a la autoorganización lo veo muy similar a Enseñar a Montar en Bicicleta (wow me tomo mucha argumentación llegar hasta acá, pero sentí que debía hacerlo .. continuemos) pues:

  • al principio tu debes guiar, dirigir, inspirar, dar instrucciones precisas para que el equipo vaya aprendiendo scrum (y el niño comience a montar en bicicleta) Acá es típico que:
    • se tiene que insistir en lo importante de los dailys y como hacerlos bien -clic aqui-
    • no falta quien diga: "soy autoorganizado entro a las 10 y me voy a las 2 ¡¡PLOP!! - prometo un post de esto - " y es necesario hablarle de compromiso, disciplina, confianza, madurez, de que la autoorganización se entiende como la capacidad del equipo de resolver independientemente su compromiso de sprint backlog sin faltar a sus compromisos laborales.
    • Timebox de las reuniones, etc.
  • luego comienzas a soltar poco a poco y es hasta probable que el equipo se caiga, aprenda y tropiece pero sigues soportándolo corriendo detrás de él agarrando el sillín/silla algunas veces.
    • Fallen experimentos
    • Propuestas de retrospectivas funcionen y otras no
  • y luego lo "dejas solo" sin dejar de acompañarlo, dándole instrucciones lejanas de cuidado, o advertencia, u otras muchas animándolo.
    • Tal vez, visitas el kanban y preguntas como van con la herramienta, si les ha servido, los felicitas o les explicas el por que de ciertas prácticas
  • hasta que ya no necesita de ti para ser autoorganizado y el equipo completamente independiente
Aclaro, se sigue necesitando del Scrum Master para remover impedimentos y realizar las otras muchas tareas, pero ya no necesitan del Scrum Master para autoorganizarse, pero sí talvez para algún cuestionamiento que los lleve a ser cada vez mejores.


Nota: No creo en coach de Scrum o Scrum Masters certificados o no, que nunca hayan practicado Scrum, no saben transmitir la esencia del mismo y el espíritu que hay detrás del Framework. En el lenguaje de la bicicleta sería: aunque no dudo que hayan casos de quienes enseñen a montar en bicicleta sin haberla montado, la experiencia de quien enseña es importante para que quien esta aprendiendo aprenda más rapido, aprenda correctamente y aprenda mejor.

Hasta acá este compartir, hasta la próxima

Saludos ágiles

Jorge Abad.

miércoles, noviembre 11, 2015

Tweets sobre Scrum: Ideas que me rondaron hoy