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

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
-----------

Prólogo de los traductores a la edición en español


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

“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):

  • 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 piloto 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

  1.  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:

  • 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)
La verdad parece que se nos olvida que en proyectos construidos en cascada de más de 6 meses (2) pasan las siguientes disfuncionalidades respecto a la parte técnica:
  1. Nos comprometemos a una fecha y no la cumplimos
  2. Las pruebas las empezamos 2 o 3 meses después de la fecha de finalización del proyecto (si es que tenemos suerte)
  3. Nos quedamos en ciclos interminables de pruebas (4, 5 o  hasta más) para poder entregar el sistema.
  4. El cliente nos acepta el producto después de dós o más ciclos de pruebas
  5. 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
Pero la realidad no es así, los equipos en general caen en "Agilidad Cosmética" que tiene como síntomas:
  • 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.
Y debido a la entrega frecuente hace que la pésima calidad del software evidencie más rápido nuestras falencias técnicas como equipo de desarrollo.

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.

























Comentarios, Aclaraciones, Notas y Referencias

  1. Presentación sobre deuda técnica (clic aquí)
  2. 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

viernes, julio 21, 2017

Algunas Ideas Claves 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:

  1. Las historias de usuario no son especificaciones
  2. 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)
  3. Es preferible una historia de usuario ambigua que una bien escrita (la razón: la ambigua invita a la conversación) (Jeff Patton)
  4. Paremos de especificar las historias de usuario comencemos a explicarlas (Jeff Patton)
  5. Es en serio, las historias de usuario tienen que ser pequeñas (ver post aquí)
    • 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
  6. Lo más importante de una Historia se usuario es que sea menos importante que la conversación (Juan Pablo Bernal)
  7. Un buen sprint backlog tiene entre 6 a 10 historias de usuario (ver más acá)
  8. 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).
  9. 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.
  10. 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.
  11. 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?
  12. Una historia de usuario debe ser construible en su totalidad durante un sprint (incluyendo pruebas, documentación, despliegue y todo lo que este en la "Definition of Done")
  13. "Las historias de usuario son DICHAS,  no escritas." / "Key point: User Stories are TOLD, not written".(Ron Jeffries)


Espero les sean útiles estas cortas ideas.

Saludos Ágiles
Jorge Abad