jueves, octubre 12, 2017
jueves, septiembre 28, 2017
¿Dónde está el problema?¿Por qué mi equipo Scrum falla continuamente sprint tras sprint?
Hola a todos
Muchas veces al visitar equipos de trabajo me encuentro con Scrum Masters en los que su equipo lleva continuamente fallando con los puntos comprometidos sprint tras sprint, y por lo general corresponden a ciertas sintomatologías.
A continuación voy a presentar algunas de las posibles causas raíz y posibles formas de solución, espero esta lista te sea útil al momento de diagnosticar a tu equipo si está atravesando por la misma situación:
|
"Cualquier parecido con la coincidencia es pura realidad"☺
Ahora para ser sincero, la no identificación oportuna de estas causas es responsabilidad del Scrum Master.(les recomiendo este post: El Paciente se Enferma de lo que el Médico Sabe. Una Invitación a no Detenerse en el Proceso de Aprendizaje -clic aquí-)
Si tienen más razones y posibles soluciones, bienvenidas sean en la zona de comentarios.
Comos siempre, bienvenido el feedack.
Saludos Ágiles
Jorge Abad
jueves, septiembre 14, 2017
Es inútil, no trates de uniformizar tus equipos Scrum
Algunos de nosotros hemos tenido la experiencia de empezar en un equipo Scrum desde cero, ya sea como Product Owner, Scrum Master o Team Member, y hemos intentado traer prácticas que hemos aprendido (y que nos han funcionado muy bien) en otros equipos pero en este:
- no son acogidas,
- las usas pero no tienen el mismo impacto.
- las usan y pronto las desechan
Lo cierto, es que cada equipo es un universo único de relaciones únicas entre sus integrantes y aunque empezaramos dos equipos con el mismo scrum master el mismo día y para el mismo producto, es muy probable que pronto (al segundo sprint - tal vez-) comiencen a existir diferencias entre las prácticas adoptadas, pues cada equipo (de acuerdo a su inteligencia colectiva) en las retrospectivas o en el avanzar de los sprints encuentra:
- accionables
- acuerdos
- experimentos y
- prácticas
Que le son útiles en su contexto único, para esos integrantes en ese momento del tiempo y para nadie más.
Por lo tanto, y cerrando rápido esta corta reflexión
- lo que le sirve a un equipo, no tiene necesariamente por que servirle a otro
- (igual en las organizaciones) lo que le sirve a una organización no tiene necesariamente por que servirle a otra
- cada equipo es un mundo diferente
- los equipos van encontrando su propia forma particular de responder al contexto y es deber del Scrum Master guiarlos en este reto.
- es necesario hacer inspección y adaptación para ir respondiendo al entorno complejo
y la obvia
- es inútil tratar de uniformizar tus equipos scrum.
Hasta acá esta corta reflexión, bienvenido el feedback y tus experiencias en la zona de comentarios.
Saludos ágiles
Jorge Abad
Notas
- Me he encontrado con equipos a los cuales les funciona bien el burdown y otros no, se contentan con el kanban.
- Este post no va en contra de las prácticas definidas por la organización, en ese caso los equipos trabajan con los artefactos, y herramientas asignadas por la organización, es más dirigido a nuestro es fuerzo de copiar y pegar indiscriminadamente sin ningún contexto.
martes, agosto 29, 2017
Datos reales comparativos entre un proyecto construido en Cascada y otro con Scrum
Hola a todos
Uno de los datos que más carecemos en nuestra industria es datos comparativos entre Cascada y Scrum basados en el mismo proyecto, tal vez por que transparentan ineficiencias de un modo de trabajo que por años defendimos todos (yo el primero) y que va de salida en el mundo del desarrollo de software a la medida.
A continuación les comparto datos de un proyecto real, correspondiente a una empresa radicada en Colombia, espero poder en un futuro cercano contar con las autorizaciones poder publicar las referencias exactas.
Espero les sea de utilidad.
Saludos ágiles
Jorge Abad
Uno de los datos que más carecemos en nuestra industria es datos comparativos entre Cascada y Scrum basados en el mismo proyecto, tal vez por que transparentan ineficiencias de un modo de trabajo que por años defendimos todos (yo el primero) y que va de salida en el mundo del desarrollo de software a la medida.
A continuación les comparto datos de un proyecto real, correspondiente a una empresa radicada en Colombia, espero poder en un futuro cercano contar con las autorizaciones poder publicar las referencias exactas.
Espero les sea de utilidad.
Saludos ágiles
Jorge Abad
viernes, agosto 18, 2017
Una guía de supervivencia a la adopción y transformación ágil: trabajando con cultura organizacional
Hola a todos
Quiero compartirles el libro de Michael Sahota que tuve la oportunidad de traducir con mis amigos: Lucho Salazar, Leonardo Agudelo y Sebastián Velásquez.
A continuación el prólogo a la edición en español y el link para descargarlo, espero lo disfruten como nosotros lo hicimos traduciendo.
Saludos ágiles
Jorge abad
-----------
Muchas cosas han pasado desde que Michael publicó el libro en 2012.
Un número de modelos de enfoques para escalar Ágil han surgido en estos últimos años, especialmente para procesos de Scrum y Kanban a escala. Hay muchos modelos, como SAFe, LeSS, Nexus, DAD, Agile Portfolio Management, Lean Management e incluso algunos creados internamente en distintas organizaciones. Y, aunque hay un riesgo de que esos modelos se usen de manera dogmática, están brindando apoyo a las empresas que los consumen en sus iniciativas Ágiles.
La transformación digital, es decir, el efecto social total y global de la digitalización, se empezó a consolidar y está dando lugar a mayores oportunidades para transformar y cambiar los modelos de negocio existentes, las estructuras socioeconómicas, las medidas legales y políticas, los patrones organizacionales y las barreras culturales, entre otros aspectos de la vida moderna digital. Y muchas industrias están apalancando su transforma-ción digital en el pensamiento Ágil, logrando con ello generar un impacto positivo en el modus vivendi de más personas en cualquier lugar del mundo.
Durante estos años hemos usado muchas de las ideas del libro de Michael, algunas de ellas con mucho éxito. Otras están en progreso en estos momentos en distintas organizaciones a las que asistimos como coaches y facilitadores Ágiles en Colombia y en otros países de Latinoamérica.
Durante este tiempo hemos comprobado que toda transformación es un proceso. Y como la vida misma, tiene sus altibajos. Es un viaje de descubrimiento. Hay un momentos en que nos encontramos cerca a la luz fulgurante de las estrellas, y hay otros donde simplemente acabamos en insondables valles de desesperación. Este libro, como las finas fragancias, es pequeño, pero encierra grandes enseñanzas, esas feromonas que necesitamos quienes lideramos estos procesos difíciles para conquistar a esa vasta mayoría de personas, equipos y áreas organizacionales que normalmente se oponen al cambio.
También hemos notado que las empresas latinoamericanas proporcionan a sus empleados muy poca educación Ágil. No se trata solo de entrenamiento, que de por sí es exiguo. Esta es apenas una de las formas para diseminar conocimiento. También se trata de coaching, mentoría, lectura, experimentación y reflexión, además de la promoción de ciclos de aprendizaje tipo sensei-senpai-kohai que habiliten a la organización para que su transformación sea sostenible en el tiempo y para crear una cultura de aprendizaje necesaria en toda transformación exitosa.
El esfuerzo ha sido monumental. Hemos visto con cierto desgano como al final de uno o más intentos de transformación, muchas empresas se resignan: los valores y principios no cambian ni cambiarán, aunque quizás los procesos y las herramientas sí.
Muchas cosas han cambiado estos cinco años, sin embargo, los distintos modelos presentados en el libro se mantienen vigentes, lo que reafirma la sospecha que teníamos los traductores cuando lo leímos por primera vez: ¡es una gran herramienta! Y por eso decidimos traducirlo con la venia del autor.
Nuestra responsabilidad como agentes de cambio Ágiles es mayúscula y estamos conscientes de la distancia y el tiempo que nos separa a los Agilistas latinoamericanos de los colegas de otras partes del planeta.
Pero esperamos que el libro de Michael y nuestra traducción sirvan de base para cerrar esta brecha.
– Medellín, julio de 2017. Jorge, Leo, Lucho, Sebastián
Puedes descargar el libro aquí y nos cuentas cómo te pareció en la zona de comentarios
Prólogo de los traductores a la edición en español
Un número de modelos de enfoques para escalar Ágil han surgido en estos últimos años, especialmente para procesos de Scrum y Kanban a escala. Hay muchos modelos, como SAFe, LeSS, Nexus, DAD, Agile Portfolio Management, Lean Management e incluso algunos creados internamente en distintas organizaciones. Y, aunque hay un riesgo de que esos modelos se usen de manera dogmática, están brindando apoyo a las empresas que los consumen en sus iniciativas Ágiles.
La transformación digital, es decir, el efecto social total y global de la digitalización, se empezó a consolidar y está dando lugar a mayores oportunidades para transformar y cambiar los modelos de negocio existentes, las estructuras socioeconómicas, las medidas legales y políticas, los patrones organizacionales y las barreras culturales, entre otros aspectos de la vida moderna digital. Y muchas industrias están apalancando su transforma-ción digital en el pensamiento Ágil, logrando con ello generar un impacto positivo en el modus vivendi de más personas en cualquier lugar del mundo.
Durante estos años hemos usado muchas de las ideas del libro de Michael, algunas de ellas con mucho éxito. Otras están en progreso en estos momentos en distintas organizaciones a las que asistimos como coaches y facilitadores Ágiles en Colombia y en otros países de Latinoamérica.
Durante este tiempo hemos comprobado que toda transformación es un proceso. Y como la vida misma, tiene sus altibajos. Es un viaje de descubrimiento. Hay un momentos en que nos encontramos cerca a la luz fulgurante de las estrellas, y hay otros donde simplemente acabamos en insondables valles de desesperación. Este libro, como las finas fragancias, es pequeño, pero encierra grandes enseñanzas, esas feromonas que necesitamos quienes lideramos estos procesos difíciles para conquistar a esa vasta mayoría de personas, equipos y áreas organizacionales que normalmente se oponen al cambio.
También hemos notado que las empresas latinoamericanas proporcionan a sus empleados muy poca educación Ágil. No se trata solo de entrenamiento, que de por sí es exiguo. Esta es apenas una de las formas para diseminar conocimiento. También se trata de coaching, mentoría, lectura, experimentación y reflexión, además de la promoción de ciclos de aprendizaje tipo sensei-senpai-kohai que habiliten a la organización para que su transformación sea sostenible en el tiempo y para crear una cultura de aprendizaje necesaria en toda transformación exitosa.
El esfuerzo ha sido monumental. Hemos visto con cierto desgano como al final de uno o más intentos de transformación, muchas empresas se resignan: los valores y principios no cambian ni cambiarán, aunque quizás los procesos y las herramientas sí.
Muchas cosas han cambiado estos cinco años, sin embargo, los distintos modelos presentados en el libro se mantienen vigentes, lo que reafirma la sospecha que teníamos los traductores cuando lo leímos por primera vez: ¡es una gran herramienta! Y por eso decidimos traducirlo con la venia del autor.
Nuestra responsabilidad como agentes de cambio Ágiles es mayúscula y estamos conscientes de la distancia y el tiempo que nos separa a los Agilistas latinoamericanos de los colegas de otras partes del planeta.
Pero esperamos que el libro de Michael y nuestra traducción sirvan de base para cerrar esta brecha.
– Medellín, julio de 2017. Jorge, Leo, Lucho, Sebastián
“Cuando se transformó en una mariposa, las orugas no hablaron de su belleza, sino de su rareza. Querían que ella volviera a ser lo que siempre había sido. Pero tenía alas”.
- Dean Jackson
Puedes descargar el libro aquí y nos cuentas cómo te pareció en la zona de comentarios
miércoles, agosto 16, 2017
Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos.
Hola a todos
Hace poco leí un gran post de Mike Cohn relacionado con como elegir el proyecto piloto: (ver el post aquí) en donde reforzaba 4 variables (más un bonus):
Hace poco leí un gran post de Mike Cohn relacionado con como elegir el proyecto piloto: (ver el post aquí) en donde reforzaba 4 variables (más un bonus):
- Duración: 3 a 4 meses
- Tamaño: Entre 1 y 4 equipos de trabajo (un equipo de máximo 9 personas)
- Importancia: Importante para la organización
- Patrocinio y Compromiso Ejecutivo: Alto
- y un Bonus: Contar con las personas correctas para hacer el proyecto (las que nos garanticen ganar esto funciona para cualquier escenario - agile o tradicional-).
El punto que quiero agregar (como fuente de mi experiencia) a esta lista de 5 puntos es:
- La Tecnología: la tecnología debe ser dominada por el (los) equipo(s) de trabajo
y ahí es donde va aporte, no tiene sentido (adicional a los 5 puntos anteriores) hacer un piloto en agile, o Scrum donde:
- la tecnología es nueva en el mercado, es decir, el proveedor nos están brindando la "valiosísima oportunidad" de ser de los primeros que la usan o implementan (¡OMG!), o
- el equipo de trabajo no conoce la tecnología, es decir:
- no se domina la arquitectura
- no se conocen los componentes
- no se conocen los retos subyacentes, las características,
- las premisas y supuestos no se dominan,
- no se conoce como hacer el tunning del sistema, entre otros.
- y aunque el equipo recibió una "muy buena capacitación" y les funcionaron "todos los laboratorios" sabemos que eso no los hace expertos en algo nuevo (que al menos requeriría seis meses de trabajo continuo para comenzar a tener cierto dominio)
Sabiendo que el propósito es generar una victoria temprana y un gran impacto en la organización, de forma que sea comparable con los proyectos en cascada de similares condiciones.
No recomiendo hacer el primer piloto en agile con tecnología desconocida (y para ser sincero tampoco en cascada), pues no se verían resultados en el mediano plazo ni de la tecnología nueva ni del método.
Mi recomendación general sería:
- hagamos un proyecto pilot en agile con que cumpla las seis premisas:
- 3 a 4 meses de duración
- Con 1 a 4 equpos de trabajo
- Importante para la organizaicón
- Patrocinio ejecutivo
- La gente correcta
- Dominio de la tecnología
- y si, aun así desean el proyecto de la tecnología nueva y retadora, pues que sea otro proyecto adicional al primero, pero:
- que "este no sea el de mostrar" que Agile funciona (pero eso sí estoy seguro que si en este proyecto hacen correctamente Agile o Scrum les aseguro que avanzará más rápido que en cascada)
- que tenga e alcance pequeño
- que cuente con alto acompañamiento al equipo de parte de expertos o personas conocedoras de la tecnología
- que la organización tenga paciencia este proyecto y su presentación de resultados,
- y que los patrocinadores tengan alta tolerancia a la frustración pues este problema no corresponde a un escenario complejo (ni mucho menos predictivo) sino a una caótico donde es difícil tener victorias tempranas (1).
Hasta acá esta corta recomendación, reflexión y lección aprendida.
Saludos ágiles
Jorge Abad
Notas, aclaraciones, comentarios y referencias
- Ver el framework de Cynefin para entender el contexto de esta afirmación (clic aquí)
martes, agosto 01, 2017
Ejemplos de Artefactos Ágiles - Inception e Historias de Usuario
Hola a todos
(les comparto un post relativamente recurrente)
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 área de gestión de incidentes empleando Kanban
Los entregables desarrollados son:
En estos links encontrarán los cuatro proyectos con los entregables citados:
Espero los disfruten y les ayude en sus proyectos.
Saludos ágiles
Jorge Abad
(les comparto un post relativamente recurrente)
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 área de gestión de incidentes empleando Kanban
Los entregables desarrollados son:
- Agile Inception
- Problema
- Elevator Pitch
- Vecindario
- Incluido, No Incluido y Pendiente por Resolver
- Product Vision Board
- User Story Map - Sin priorizar
- RoadMap (artefacto nuevo que estoy desarrollando y me esta ayudando mucho a identificar el MVP y el crecimiento orgánico del producto)
- User Story Map - Priorizado
- RoadMap Actualizado
- Historias Epicas
- Historias de Usuario
- Estimación de Pivote
- Calculo Costo y Tiempo
- Restricciones
- Arquitectura Fisica
- Arquitectura de componentes
- Diagrama de Contexto
- ¿ Que no nos deja dormir ?
- 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 Velocidad
- Gráfica de Release Burn Up
- Mejoras identificas cada sprint
En estos links encontrarán los cuatro proyectos con los entregables citados:
- Se lo tengo -Se Lo Tengo! es una startup establecida como canal de adquisición de productos y servicios que permite a cualquier persona vender y comprar de manera fácil mediante un sistema de fidelización por puntos sin restricciones de localización. (dar clic aquí)
- SaluCloud -Es un proyecto para gestionar diferentes áreas de las IPS que necesitan las instituciones prestadoras de servicios de salud.- (dar clic aquí)
- EduCool - Sistema para administrar los procesos de instituciones eductativas - (dar clic aquí)
Espero los disfruten y les ayude en sus proyectos.
Saludos ágiles
Jorge Abad
sábado, julio 29, 2017
Noticia Falsa: En cascada no existía deuda técnica
Hola a todos, hace poco compartía con un compañero el cual trabajó durante mucho tiempo en cascada y ahora esta comenzando a trabajar con scrum y esta viéndose en unos retos bien importante, el cual me argumentaba que:
- en cascada los problemas no teníamos los problemas de deuda técnica que existen en ágil. En cascada siempre entregabamos...
no les niego que mi cara fue similar a esta.
Vamos primero a aclarar términos:
 |
| Ver más sobre deuda técnica en (1) |
- Nos comprometemos a una fecha y no la cumplimos
- Las pruebas las empezamos 2 o 3 meses después de la fecha de finalización del proyecto (si es que tenemos suerte)
- Nos quedamos en ciclos interminables de pruebas (4, 5 o hasta más) para poder entregar el sistema.
- El cliente nos acepta el producto después de dós o más ciclos de pruebas
- Salimos a producción muertos de miedo y estabilizando el sistema por más de 6 meses (muchas de las condiciones de aceptación de un producto en cascada dice cuando por 2 meses no aparezcan problemas en producción).
Estas disfuncionalidades son mayormente creadas por la pobre calidad técnica y lo que estamos tratando de hacer es entregar el proyecto con fuerza bruta.
¿Y en Agile como es?
La verdad es que, si tenemos excelencia técnica (buenas prácticas ágiles, buena ingeniería, buena arquitectura), esto no se presentará (o al menos se reducirá enormemente su impacto) y la imagen de arriba hará honor a lo que profesamos:- Entregamos software de valor frecuentemente
- Y la medida de progreso es software funcionando
- Solo se centra en el proceso scrum (o como sea que lo llamen) y no en las personas.
- Los equipos no mejoran sus prácticas técnicas.
- Los scrum masters solo se enfocan en mejorar la comunicación del equipo cuando hay muchos aspectos a mejorar.
- Las retrospectivas son las mismas hace 5 sprints.
- Los equipos no son retados técnicamente por el scrum master (ver más acá Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo).
- No se gestiona la deuda técnica.
- No hay una preocupación seria por parte del equipo de la excelencia técnica.
Algunos tweets
Para terminar quisiera compartirles algunos tweets relacionados con la deuda técnica y la excelencia técnica tanto en cascada como en ágil.— Jorge Hernán Abad L. (@jorge_abad) April 28, 2016
No monitorear, ni pagar la #DeudaTecnica cada sprint, es una característica del #BadAgile https://t.co/t8Ub2tCrKO#TechnicalDebt #Scrum— Jorge Hernán Abad L. (@jorge_abad) May 17, 2017
Otra Definición de #DeudaTecnica— Jorge Hernán Abad L. (@jorge_abad) February 2, 2017
Cuando terminas trabajando para el sistema y no el sistema para tí#technicalDebthttps://t.co/zO40WzAp3O
La deuda técnica creciente termina por agotar la velocidad del equipo #Scrum y ocasionando la generación de cero valor #Agile #TechnicalDebt— Jorge Hernán Abad L. (@jorge_abad) May 5, 2016
Cualquier intento de escalar #Scrum sin contar con Excelencia Técnica ni Gestión de la Deuda Técnica muy seguramente será un fracaso— Jorge Hernán Abad L. (@jorge_abad) July 24, 2017
#lesaAgilidad— Jorge Hernán Abad L. (@jorge_abad) April 25, 2017
Si como equipo no estas mirando, midiendo, controlando la deuda tecnica #techinicalDebt #agile #scrum #fail
La deuda técnica es curable si se diagnóstica a tiempo #techinicalDebt— Jorge Hernán Abad L. (@jorge_abad) May 20, 2016
3 ideas:— Jorge Hernán Abad L. (@jorge_abad) April 20, 2016
El sw con el tiempo se degrada
la deuda técnica debe ser identificada y gestionada
Sin excelencia técnica no hay agilidad
Haz buen software o alguien (talvez tu mismo) terminará pagando la deuda técnica de tu proyecto #agile #scrum pic.twitter.com/N7nykg2rH2— Jorge Hernán Abad L. (@jorge_abad) March 16, 2016
Hacer #Scrum sin gestionar la #DeudaTecnica es hacer problemas de forma iterativa, incremental y en ciclos cortoshttps://t.co/t8Ub2tkQme— Jorge Hernán Abad L. (@jorge_abad) June 21, 2017
Ya sea en cascada o en #Agile sino hay excelencia técnica se va directo al fracaso, eso es indistinto del método.— Jorge Hernán Abad L. (@jorge_abad) May 30, 2017
Comentarios, Aclaraciones, Notas y Referencias
- Presentación sobre deuda técnica (clic aquí)
- En proyectos más pequeños de tamaño (5 meses o menos) las disfunciones técnicas que tiene cascada para desarrollo de software no se evidencian tan fácilmente como en proyectos grandes, pues en últimas el mal código siempre generará impacto tipo de impacto en el tiempo, costo y satisfacción del cliente independiente del tamaño del proyecto (Gracias Luis Mulato @LuisMulato por el feeback y correciones respecto a este último punto y al post)
miércoles, julio 26, 2017
Un tweet sobre #Agile
#Agile reduce costos pero no es más barato. Un equipo de desarrollo siempre costará lo mismo, el enfoque al valor es la gran diferencia.
— Jorge Hernán Abad L. (@jorge_abad) July 26, 2017
viernes, julio 21, 2017
Algunas ideas sobre Historias de Usuario
Hola a todos:
Les quisiera compartir un listado de ideas centrales sobre historias de usuario que por lo regular comparto en los entrenamientos en Scrum:
- Las historias de usuario no son especificaciones
- Una historia de usuario debe ser tan pequeña que obligue a una conversación cara a cara donde todos entiendan mejor el problema (Leonardo Agudelo)
- Es preferible una historia de usuario ambigua que una bien escrita (la razón: la ambigua invita a la conversación) (Jeff Patton)
- Paremos de especificar las historias de usuario comencemos a explicarlas (Jeff Patton)
- Es en serio, las historias de usuario tienen que ser pequeñas
- Una buena historia de usuario debe tomar entre 3 y 5 dias persona de esfuerzo para lograr el DONE
- Una buena historia de usuario tiene entre 4 a 8 criterios de aceptación
- Lo más importante de una Historia se usuario es que sea menos importante que la conversación (Juan Pablo Bernal)
- Un buen sprint backlog tiene entre 6 a 10 historias de usuario
- Las historias de usuario no son requisitos, son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante (Lucho Salazar).
- Es un error decir la historia de usuario está mal especificada, pues la historia de usuario no es una especificación, es mejor que este "mal escrita" por que invita a una conversación y una aclaración sobre la misma.
- Se llaman historias de usuario no "especificaciones de usuario", por lo tanto el énfasis se debe hacer en la historia que cuenta el usuario y no en lo que esta escrito o tratado de especificar.
- Las historias de usuario deben ser porciones funcionales end-to-end, que cuando funcionen se implementen agreguen valor, o sea, pasen exitósamente el siguiente test:
- ¿puedo ponerla en producción?
- ¿un usuario final puede usarla sin necesidad de algun truco o script extraño?¿es decir, se puede acceder desde la interfaz de usuario y funciona completamente?
Espero les sean útiles estas cortas ideas.
Saludos Ágiles
Jorge Abad
jueves, julio 20, 2017
Un tweet sobre Historias de Usuario
Lo más importante de una Historia se usuario es que sea menos importante que la conversación#Agile #Leadership #DreamTeam
— Juan Pablo Bernal M. (@NeoBernal) July 12, 2017
miércoles, julio 12, 2017
Notas del Taller de Retrospectivas con Ágiles México
Notas del taller de Retrospectivas en @AgilesMexico parte 1 de 2 pic.twitter.com/UhJHlDRLnK
— Jorge Hernán Abad L. (@jorge_abad) March 17, 2017
Notas taller de Retrospectivas en @AgilesMexico parte 2 de 2 pic.twitter.com/dUCPhejlr4
— Jorge Hernán Abad L. (@jorge_abad) March 17, 2017
Charla de retrospectivas por @jorge_abad en @AgilesMexico pic.twitter.com/UGA2Y4gOiY
— Carlo Gilmar (@CarloGilmar) March 17, 2017
domingo, julio 09, 2017
La Diferencia entre el Cumplimiento y Entender el Propósito
Hola a todos
Hace poco salí con mi familia y unos amigos de paseo y nos encontramos en una situación vergonzosa: íbamos todos en el mismo carro de regreso al hotel en carretera destapada (no pavimentada) y de repente a unos 10 metros de nosotros un motociclista tiene un accidente, se cae de la moto con su novia o esposa, e inmediatamente los dos automóviles que estábamos cerca nos detuvimos a auxiliar a la pareja, no fue grave el incidente, algunas raspaduras y heridas leves. todos sacamos nuestro botiquín y nos encontramos conque ambos contábamos con lo mínimo que nos exige la ley (confieso que ese el mismo que yo tenía en mi carro):
- Un pedazo de gaza
- Algodón
- Guantes
- Un desinfectante (alcohol antiséptico)
- Un aplicador
- Cinta microporo
Con esto tan insignificante no logramos atender las heridas del motociclista y su novia, el recuadro de gasa era insuficiente necesitábamos más para cubrir la herida en la mano y que el pudiera conducir su moto, el alcohol lo acabamos rápido, realmente estábamos limitados; de suerte que a los pocos minutros pasó otro automóvil con un botiquín serio (no el que teníamos los dos carros - que era el para cumplir la regulación-) y pudimos auxiliar y prestar los primeros auxilios a la pareja, vendarlos etc.
De este pequeño incidente me quedaron varias enseñanzas.
- Teníamos un botiquín solo para cumplir con la regulación colombiana, pero no nos sirvió para un leve accidente
- No entendíamos el propósito del botiquín en nuestros carros, si fuéramos conscientes que con este atenderemos un herido ya sea nuestro o externo no seríamos tan irresponsables de andar con un botiquín de juguete.
- Cuando nos centramos en el cumplimiento y no entendemos el propósito nuestras soluciones no son las correctas.
- El botiquín no esta en mi carro para evitar sancionado por la ley, sino para ayudar a salvar mi vida, la de mi familia, o de alguien que requiera mi ayuda.
- Cambiar inmediatamente el botiquín de primeros auxilios de mi auto.
Y extrapolando esto a la agilidad
- No podemos usar frameworks y metodologías como SCRUM, Kanban, XP, SAFe, LESS sin saber que son y cual es su propósito y el problema que pretenden resolver
- Sin propósito cualquier implementación de Agile se hará por cumplir o por moda y con seguridad carecerá de los elementos necesarios para ser exitosos en su contexto.
- Tener personas ejecutando roles (PO, SM, Team Members, etc) en los cuales ellos no tengan claro el propósito y la razón de ser del mismo llevará a implementaciones erróneas e ineficientes (ya lo he vivido, de seguro ustedes también)
- Igualmente no tener claro el por qué de los artefactos y de las ceremonias, hará que estos sean implementados de forma incorrecta y no proporcionarán los resultados y beneficios esperados. (ya lo he vivido, de seguro ustedes también)(1)
Unas cuantas preguntas para cerrar:
- ¿sabes cual es propósito de tu rol?
- ¿por que usas scrum, y no xp, u otro framework?
- tu transformación hacia ágil tiene propósito o es solo ponerse a la moda
- ¿sabes por que las historias de usuario deben ser pequeñas? (Es en serio, las historias usuario tienen que ser pequeñas (clic aquí) )
- ¿Tienes claro que el MVP - Mínimo Producto Viable - debe ser lo mas pequeño posible? ¿o tu MVP es de todo el producto?
Consejo:
- Busca siempre entender cual es el propósito de lo que haces y esto como suma al propósito general.
Bueno hasta acá este compartir
Saludos ágiles
Jorge Abad
Notas, aclaraciones, comentarios y referencias
- Todo esto me hace recordar mi anterior reencarnación en la que fui ingeniero civil (ejercí esta hermosa profesión 3 años antes de adentrarme de lleno al apasionante mundo de la ingeniería de software) y resulta que existe un método bien claro para diseñar la estructura de un edificio para lo cual se requiere un ingeniero civil calculista que determine de que tamaño son las estructuras y materiales que deben tener (concreto, acero, etc), pero en Colombia los maestros de obra en los barrios populares construyen (fuera de la ley) estructuras de 1, 2, 3, hasta 4 pisos (si no es más - ojala no-) replicando lo que esquemas que han visto en las construcciones en las que han trabajado con ingenieros civiles pero estas soluciones no son ni las mejores costo-eficientes, y ni se sabe si resistirán las calidades sísmicas de la zona en la que se encuentran.
viernes, junio 30, 2017
Tweet sobre DevOps
"Hasta que el código no esté en producción, en realidad no se está generando ningún valor, porque es WIP atrapado en el sistema" #devOps pic.twitter.com/1RwBcvmKYv
— Mauro Strione (@MauroStrione) June 24, 2017
jueves, junio 22, 2017
Antipatrón de Scrum : El Scrum Master Dirige la Retrospectiva en Lugar de Facilitarla
Hola a todos
Una de las disfuncionalidades y punto de mejora que he encontrado en los equipos Scrum, radica en que el Scrum Master (SM) (ya sea que venga del mundo de la gerencia de proyectos, o acostumbrado a un liderazgo impositivo) al momento de realizar la retrospectiva reúne al equipo (1), y aunque realiza las actividades propias de una retrospectiva (2)(3), cada actividad cierra con sus conclusiones, es decir:
- decide cuales fueron las causas principales de por qué les fue bien o mal durante el sprint
- decide cuales son las acciones de mejora, acuerdos y experimentos a realizar
- el equipo esta allí solo para estar de acuerdo con sus decisiones.
Es decir, dirige la sesión en lugar de facilitara.
Problemas de este enfoque
- no permite la auto-organización
- queda el SM como el único responsable de decidir que se hace, y por ende a quien culpar [les sugiero leer este post de Martín Alaimo sobre la responsabilidad del equipo y el único responsable (4)] de una buena o mala estrategia.
- el equipo solo sirve para hacer lluvia de ideas pero no decide, pues el SM decide por el equi
- el equipo no esta empoderado tiene voz pero no voto
- el equiipo no madurará, pues siempre le dirán que hacer y no asumirá consecuencias.
- El SM no es un facilitador, es más alguien que dirige al equipo y este depende de él para todo (se sigue un esquema de Comando y Control - típico de la gerencia de proyectos - )
- Se esta trabajando con un grupo y no con un equipo (4)
Soluciones
- El SM es realmente un facilitador de la reunión(5), es decir el SM esta ahí, para ayudar al equipo a encontrarse, ser su espejo, no dirige sino que facilita, es alguien que cuenta con instrumentos y experiencias para facilitar correctamente la sesión de retrospectiva de su equipo (6).
- Al finalizar cada paso de la retrospectiva (3) el SM invita al equipo a que priorice, reflexione y tome decisiones sobre:
- problemas
- oportunidades de mejora
- experimentos
- planes
- acuerdos
- cambios a realizar entre otros.
Beneficios de la Solución Propuesta
- El equipo se empodera de sus problemas y soluciones
- Todos adquieren un compromiso entre pares, nadie les dice que hacer, ellos acuerdan que ahcer.
- El equipo tiene voz y voto
- Si el equipo falla, el equipo aprende y mejora (en el esquema anterior el SM es el culpable de elegir una mala estrategia)
- El equipo comienza a sentirse responsable y emerge la autoorganización
- Si el equipo durante el sprint no esta tomando las acciones que se comprometieron,
- entre ellos pueden llamarse la atención (es más fuerte la presión social que el compromiso ante una orden) o
- el SM puede interpelarlos con una pregunta poderosa puede hacerlos conscientes de la desviación de lo comprometido por ellos
- El equipo se escucha entre sí (recordemos que las mejores ideas vienen de cualquier parte)
Bueno hasta acá este corto compartir, bienvenido el feedback, los comentarios y las experiencias.
Saludos ágiles
Jorge Abad
Aclaraciones, Notas, Comentarios y Referencias
- Recordemos que el equipo Scrum esta constituido por Product Owner, Equipo Desarrollador (el cual es multidisciplinario), y Scrum Master
- En esta página podrás encontrar cientos de actividades https://plans-for-retrospectives.com/es/
- Recordemos que un buen guión de retrospectiva (según el libro Agile Retrospectives de Diana Larsen y Ester Derby) cuenta con:
- Armar el escenario
- Recolectar datos
- Indagar
- Decidir que hacer
- Cerrar
- Compartiendo la responsabilidad. Hacia Un Equipo Real.por Martín Alaimo (clic aquí)
- Según comparte Martín Alaimo en su libro "Facilitador de Equipos Ágiles: El Camino de un Coach hacia la Agilidad Empresarial"
- La facilitación de grupos: es un proceso por el cual una persona cuya elección es aceptada por todos los miembros del grupo, que es neutral y no tiene autoridad sustancial en la toma de decisiones, diagnostica e interviene para ayudar al grupo a identificar y resolver sus problemas y tomar decisiones y para así, aumentar su efectividad. (Schawarz, 2002)
- La posible agenda de una retrospectiva puede ser algo como [Agenda Scrum] Pasos para Realizar la Retrospectiva
martes, junio 20, 2017
Nexus y la Deuda Técnica
Les comparto el meetup que se realizó el 8 de Junio en la ciudad de Mexico sobre Nexus (un framework para escalar Scrum) y la Deuda Técnica.
https://www.meetup.com/es/Agile-Mexico-Meetup/events/240553474/
Nexus con @jorge_abad https://t.co/zaRqDmeJ8w— Rox (@jeri4queen) June 9, 2017
Dolores de deuda técnica con @jorge_abad https://t.co/ZDcilL3Gxa— Rox (@jeri4queen) June 9, 2017
Sobre el Compromiso del Sprint
El Compromiso no es sobre una promesa o sobre firmar con sangre, es sobre hacer todo lo que está en nuestros medios para tener éxito. https://t.co/P6LL1MGX8o
— Jorge Hernán Abad L. (@jorge_abad) June 18, 2017
Commitment is neither a promise, nor signing with blood, but trying everything you can to succeed ^ @Koen_V pic.twitter.com/ezz9clu8AG
— AgileFortune (@AgileFortune) June 18, 2016
viernes, junio 16, 2017
El Planning, el Tasking, el Tablero Kanban, la Guía de Scrum y un Tip Poderoso para “Oler” Impedimentos
Hola a todos, este es uno de los post que hace tiempo tenía
pendiente por escribir y por fin se alinearon los astros y pude escribirlo.
Empecemos, según la Guía Oficial de Scrum (1) el planning
consta de dos partes:
- Tema Uno: ¿Qué puede hacerse en este Sprint? (conocido como “El Qué”): El cual consiste en la identificación del Objetivo del Sprint y la lista de ítems de backlog que hacen parte del producto que si se completan lograrían el Objetivo del Sprint
- Tema Dos: ¿Cómo se conseguirá completar el trabajo seleccionado? (conocido como “El Cómo”): El cual consiste que el Equipo de Desarrollo decide cómo construirá esta funcionalidad para formar un Incremento de producto “Terminado” durante el Sprint que cumpla con el Objetivo y contenga los ítems seleccionados en el paso anterior más el plan para terminarlos.
Adicionalmente, para el tema 2 dice claramente:
“El Equipo de Desarrollo por lo
general comienza diseñando el sistema y el trabajo necesario para convertir la
Lista de Producto en un Incremento de producto funcional. El trabajo podría ser
de tamaño o esfuerzo estimado variables. Sin embargo, durante la Planificación
del Sprint se planifica suficiente trabajo como para que el Equipo de
Desarrollo pueda hacer una proyección de lo que cree que puede completar en el
Sprint que comienza. Para el final de esta reunión, el trabajo planificado por el Equipo de Desarrollo para los primeros
días del Sprint es descompuesto en unidades de un día o menos.” (Esto último
es conocido en el mundo de Scrum con el Tasking, o la descomposición en tareas
de los ítems de backlog - como la palabra misma lo sugiere-)
Aquí vemos dos cosas:
- Se sugiere que el trabajo se descomponga de forma gradual en unidades, o sea, NO SE DESCOMPONGA TODO A PRIORI en el planning del sprint (ya sea por timebox o conveniencia), sino que se identifique claramente las tareas próximas de lo próximo que se va a hacer y luego se descomponga el resto cuando estemos cercanos a construirlo (esto es conocido en el mundo de gerencia de proyectos como Planeación Gradual o Rolling Wave Planning – la cual empleamos nosotros ampliamente en el mundo ágil –). Acá quiero hacer una precisión, nunca lo he hecho así, siempre sugiero o hago la descomposición de todas las historias de usuario en tareas durante el planning –y nos ha ido bien –, haré el experimento y lo compartiré.
- Lo segundo que me parece MUY PODEROSO es descomponer el trabajo en unidades de UN DÍA O MENOS.
Y es en esto último donde uno dice: “Claro, tiene sentido,
de esa manera todos los días se finalizará algo y de esa forma se sentirá el progreso y se identificarán fácil los impedimentos y puntos de atasque".
Basado en lo anterior vienen los siguientes puntos
Cómo he trabajado el tasking o cómo lo he visto
Este ejercicio de descomponer las historias de usuario en tareas
de un día o menos (léase Tasking), y me he encontrado con equipos que han
decidido manejarlo de diferente manera, el punto no es discutir cuál es la
mejor, es mejor pensar, con cual se siente más cómodo mi equipo, adicionalmente
puede que lo hagan de una forma durante un tiempo y luego cambien a otra
(recordemos el principio básico de la gestión empírica “Inspección y
Adaptación”), volviendo al tema las formas de tasking que he observado son:
Forma de tasking
|
Observación
|
·
Dividir la historia de usuario en tareas de
tamaños de unidades entre 1 y 8, así: 1h, 2h, 3h, 4h, 5h, 6h, 7h, 8h
|
La verdad esta no me gusta, lo que he encontrado es que no somos
buenos estimando en esta forma, pues la precisión aun a nivel de tareas aún
es baja en desarrollo de software, adicional abre el espacio a la
microgestión que limita al equipo y no permite que el equipo aprenda.
|
·
Dividir historia de usuario en las tareas de
tamaños de 2h, 4h, 6h, 8h
 |
Esta forma me gusta, brinda amortiguación si se falla en la
estimación.
|
·
Dividir la historia de usuario en las tareas
de tamaños de 2h, 4h, 8h
|
Esta es la que más me gusta, por la misma razón de la anterior,
adicionalmente permite que falles, aprender, mejorar, da más libertad al
equipo.
|
·
Dividir la historia de usuario en tareas sin
horas pero garantizando que cada tarea es menor a un día
 |
Esta forma la he visto en equipos muy maduros en los cuales la
confianza y transparencia son una constante presente en su día a día.
|
Ahora el Super Tip
Este tip me lo enseño Silvia Lozano (@sila_zenufana) – y me ha servido
montones con los equipos que he tenido la suerte de estar y acompañar –, quien
me sugirió en el tablero kanban poner UN
PUNTO por cada día que permanece la tarea en la zona del WIP (“Work In
Progress” o “Work in Process”) de esta manera se identificará que una tarea requiere ayuda si tiene más de
DOS PUNTOS, pues recordemos que como tenemos por regla (o sugerencia) que
las tareas no deben durar más de un día, si las tareas en el tablero kanban
tienen DOS PUNTOS O MÁS significa que:
- Existe un posible impedimento
- Existe una posible dificultad en desarrollar la tarea
- Existe una posible falta de foco o de habilidad por parte de desarrollador que esta trabajando en ella
- Se estimó de una forma muy optimista o con falta de conocimiento del real tamaño
- Existe un desbordamiento de alcance
- O es un punto de mejora para discutir en la retrospectiva
En cualquiera de los anteriores es un punto donde tanto
Scrum Master como Equipo observan un punto en el que hay que hacer intervención.
OJO: Lo anterior funciona muy bien si tenemos la buena práctica
que siempre haya en el tablero una tarea por persona del equipo – recordemos que
solo somos capaces de hacer una cosa a la vez, o sea en el WIP una persona no
puede tener más de dos tareas – o sea,
que en el WIP si el equipo tiene 4 integrantes a lo sumo existirán 4 post-it (o
pósit (2)) a la vez que representan una tarea por cada uno de ellos.
Cerrando
Espero que lo compartido sea de utilidad en tu equipo
Scrum, y para terminar tres preguntas
- ¿Cuándo fue la última vez que leíste la guía oficial de Scrum?
- ¿Qué descubrimiento has hecho?
- ¿los puedes compartir?
Bienvenida la retroalimentación y sus comentarios.
Saludos ágiles
Jorge Abad
Notas, Aclaraciones, Comentarios y Referencias
- La que se encuentra en Scrumguides.org
- Es correcta esta forma de escribirlo, la RAE lo permite ver acá Pósit http://dle.rae.es/?id=TnfXVsj
Suscribirse a:
Entradas (Atom)