miércoles, octubre 31, 2018

Fail - Contratar el MVP con Alcance, Tiempo y Costo Fijo

Cada vez me encuentro más con empresas que dicen:

"Ok entendí qué es un #MVP, entonces constrúyanlo con un contrato a alcance, tiempo y costo fijo"

Predecir alcance, tiempo y costo en escenarios de #VUCA es imposible.

---

¿Que modelo recomiendo usar ?

Para todo tipo de proyecto o producto de desarrollo de software recomiendo, en primer lugar no ceder frente a las presiones del cliente (no es profesional, y realmente a el no le conviene aunque así lo crea), luego de ahí hacer cualquiera de los siguientes contratos:

1. Tiempo y materiales
2. Tiempo y materiales con tiempo fijo
3. Tiempo y materiales con costo fijo
y por último
4. Estimación por sprint o estimación por trabajo mensual (implica bajo riesgo con orden de trabajo mensual)
5. Tiempo y materiales con alcance fijo (no recomiendo pues implica levantamiento y perdemos flexibilidad... cosa que nos brinda el enfoque agile)
¿y ustedes que han hecho en estos casos? ¿que recomiendan?


miércoles, octubre 24, 2018

Tip sobre Proyectos y Contratos Ágiles

"Hacer un Producto/Proyecto Ágil con un contrato tradicional (alcance, tiempo y costo fijos) es un completo dolor de cabeza para todos -cliente y proveedor-. Es como jugar fútbol con las reglas del rugby.

Tip: una de las tres restricciones debe liberarse, preferiblemente el alcance."

_



lunes, octubre 15, 2018

Consejo: Que tus Historias de Usuario no sean como Bruce Willis "Duras de Matar"



Hola a todos

Frecuentemente encuentro Product Owners, Scrum Masters, Equipos e Interesados que tienen un concepto erróneo del tamaño de las Historias de Usuario (HU), siendo estos gigantes (HU con una o más hojas de descripción) que no cumplen ni las tres CCC (1) ni el criterio INVEST (2), pues bien, una metáfora que me ha servido para generar la comprensión que deseo es que 

las historias de usuario no pueden ser como Bruce Willis "Duras de Matar" y sobrevivir varios sprints, estas deberían morir en el sprint en que se identificaron construir 

y si la construcción toma varios sprints, significa que realmente no eran HU sino Historias Épicas.

Me explico, una HU es un pedazo pequeño y funcional de software, varias veces he compartido que lo ideal es que tome a lo sumo 3 a 4 días de esfuerzo freelance - ojalá menos tiempo (4)-, es decir, que la suma de todas las horas invertidas no supere este cantidad de tiempo (incluyendo descanso, idas al baño, tomar un café, etc.), por lo tanto, las HU deberían morir en el sprint  en el que el equipo las seleccionó para desarrollarlas (recordemos que en Scrum el Product Owner -P.O.- tiene el Product Backlog priorizado y durante el Planning el PO explica las historias priorizadas al Equipo y este las selecciona para ser parte del Sprint Backlog), en consecuencia, si tu equipo tiene HU tipo Bruce Willis, empleen criterios de división (5)(6)(7) hasta que estas tengan el tamaño apropiado para el sprint y así todas puedan fallecer en el sprint en que se identificaron (recordemos una buena eurística es que un Sprint Backlog tenga entre 6 a 10 historias de usuario).


Importante: Si la HU tiene impedimentos no corresponde al caso tratado en este post, es otra historia, y deberíamos preguntarnos varias cosas:
  • ¿Comenzamos a desarrollar una HU con impedimentos?¿dependencias?
  • ¿Si lleva varios sprints con el impedimento cuál es la efectividad del SM, PO y la organización para removerlo?

Bueno, hasta acá este corto compartir


Saludos ágiles

Jorge Abad






Notas, Aclaraciones, Comentarios y Referencias

  1. Las tres CCC - Artículo Original escrito por Ron Jeffries - clic aquí -.
  2. El Criterio INVEST - INVEST in Good Stories, and SMART Tasks. Bill Wake. - clic aquí -.
  3. Es en serio, las historias usuario tienen que ser pequeñas -- clic aquí -.
  4. Esfuerzos Sugeridos de Historias de Usuario según la Duración del Sprint - - clic aquí -.
  5. Leído y Recomendado: Patrones de División de Historias de Usuario o Cómo Dividir una Historia de Usuario -- clic aquí -.
  6. Un Método Adicional de División de Historias de Usuario: Criterio de Equipo o Hasta Acá Llegamos - - clic aquí -.
  7. Algunas Ideas Claves sobre Historias de Usuario - - clic aquí -.
  8. En el libro: Historias de Usuario, Una Visión Pragmática (clic aquí) también encontrarás ejemplos de como dividir épicas en historias de usuario.

viernes, octubre 05, 2018

Lanzamiento del libro: Historias de usuario: Una visión pragmática. Por Jorge Abad y Lucho Salazar

Hola a todos

El día de hoy, segundo dentro de las Jornadas Ágiles Latinoamericanas 2018 -http://agiles2018.agiles.org/ - mi gran amigo y colega Lucho Salazar (@LuchoSalazar) y yo lanzaremos el libro "Historias de usuario: Una visión pragmática", el cual hemos escrito con el propósito de compartirles nuestras experiencias facilitando y acompañando a equipos construyendo productos grandiosos empleando este instrumento.

Espero lo disfruten leyéndolo y usándolo como nosotros al escribirlo. A continuación les comparto el prólogo del mismo.

Saludos Ágiles
Jorge Abad






Prólogo
Con historias y contando historias es como las culturas se hacen más fuertes y sobreviven. Las historias generan conexiones entre los emisores y los receptores y hacen que unos y otros se conviertan en un solo grupo, un solo equipo, un solo ser.


Las historias son un poderoso medio para fomentar la cooperación y la enseñanza de muchas cosas y las historias de usuario, tal y como las conocemos, no son la excepción a esta condición. Estas permiten crear un vínculo entre usuarios o consumidores y desarrolladores de productos. Y esta relación es el primer gran paso hacia la creación y pináculo de productos admirables, que influencien positivamente a las personas que los usen o consuman e incluso cambien para mejorar su estilo de vida.


Las historias de usuario permiten a los equipos virtuosos construir los productos correctos, incluso antes de pensar en hacerlo de la manera correcta (el método o las prácticas). Nos permiten concentrarnos en el valor de los componentes de cada producto y de cómo estos componentes hacen o harán resonancia unos con otros, en vez de involucrarnos directamente desde el inicio del esfuerzo de desarrollo en los detalles del producto o en los intríngulis de la tecnología que usaremos para construirlo.


En el caso particular del desarrollo de software, las historias de usuario son el primer movimiento de esa sinfonía que es el descubrimiento del producto y de sus características. Las historias de usuario nos ayudan a entender la proposición de valor del producto desde sus inicios, nos ayudan a anticiparnos a la gran incógnita que supone si los usuarios efectivamente usarán o no el producto, nos permiten interactuar no solo con los usuarios e interesados internos, sino también con los consumidores finales del mismo.


En este libro hemos recogido algunas de las formas de hacer las cosas cuando de historias de usuario se trata, es una visión, la nuestra, soportada en la experiencia de muchísimos años no solo en proyectos y esfuerzos de desarrollo con pensamiento Ágil y Lean, sino con otros enfoques y métodos que a estas alturas son considerados tradicionalistas.


Hemos acompañado y ayudado a cientos de equipos en docenas de empresas, en Colombia y en otros países. Han sido cientos o miles de iteraciones en conjunto, cientos de personas con las que hemos experimentado continuamente y hemos encontrado algunos escenarios exitosos, otros no tanto; pero hemos crecido en el proceso. Y sobre este aspecto, que nos haya funcionado a nosotros no quiere decir que les funcione a otros; como siempre, el llamado es a experimentar en cada escenario, en cada momento e ir analizando qué funciona y qué no en sus propios espacios y ambientes.


Al hablar de historias de usuario es necesario hablar de eXtreme Programming (XP), el contexto en el que nacieron; pero también es necesario hablar de Scrum, el contexto en el que más se usan hoy día. Sin embargo, en lo posible trataremos de ser agnósticos al marco de trabajo. Hablaremos indistintamente de iteraciones o sprints para referirnos a lo mismo.


Quienes nos conocen saben que llevamos escribiendo varios años sobre este tema que nos apasiona. De hecho, el libro es una recopilación de todos esos artículos en nuestros blogs:


Lecciones Aprendidas (http://www.lecciones-aprendidas.info/) y


Gazafatonario (http://www.gazafatonarioit.com/).


Pero los hemos enriquecido con numerosos ejemplos, les dimos un hilo conductor en el sentido en que creemos es mejor abordar su lectura, aunque nada evita que se haga en direcciones diversas.


Hemos dedicado mucho tiempo y espacio a tratar el tema de lo que significa tener buenas historias de usuario (INVEST) y hemos hecho énfasis repetidamente en que estas son un instrumento de conversación entre los miembros involucrados en el desarrollo de productos, software o no. En la parte final, incluimos el Lienzo para Conversaciones sobre Historias de Usuario, ampliamente detallado y listo para uso, una herramienta, un medio de comunicación, para promover y facilitar las conversaciones que se dan o deben darse alrededor de las historias de usuario. Una herramienta visual para documentar diferentes aspectos o dimensiones de historias de usuario nuevas o existentes en el backlog de producto.


Así es que bienvenidos a este libro y así como lo plasmado acá fue exitoso para nosotros, esperamos sea útil para ustedes, dándole aplicabilidad en su contexto.

Pueden encontrar el libro en Amazon:

Formato Kindle:
https://www.amazon.com/dp/B07HLYX68Z


Formato Tapa blanda:
https://www.amazon.com/gp/product/1723933562


Y como siempre, bienvenida cualquier retroalimentación.


Jorge y Lucho



lunes, septiembre 24, 2018

Tu Equipo Ágil no comienza siendo Ágil. Unas poderosas tres razones.



Muchas veces pensamos que por el hecho de poner a personas juntas, pedirles que le pongan un nombre al equipo, asignarles un backlog, automáticamente se convierten en un equipo (1), y no solo eso, creemos que al primer sprint el equipo va tener la velocidad (ej: 50 puntos por sprint)  que planearon - http://www.lecciones-aprendidas.info/2017/12/un-cuarto-metodo-para-estimar-la-velocidad.html -  y que con esa velocidad podremos terminar en una fecha determinada el primer release ( ej: si el primer release se estima en 350 puntos, lo tendremos en 7 sprints).

La verdad, esto es lejano de la realidad, los equipos toman un tiempo en crearse y madurarse - tal vez  8 sprints, más o menos, y esto dependerá de muchos factores - y alcanzar un buen desempeño, en este post compartiré las razones por las cuales esto se presenta y algunas recomendaciones para ayudarte en este proceso.



1. La Curva de Tuckman



Este modelo muestra las diferentes etapas por las cuales pasa un equipo (2),  ella muestra el esfuerzo que toma lograr el mismo estado de desempeño inicial en el cual se formo el equipo. Solo imaginémonos haciendo parte de un equipo de fútbol, rugby, baloncesto, voleibol, musical - en fin cualquier equipo - y el esfuerzo que nos toma acoplarnos, las veces que debemos jugar / tocar  juntos para sentirnos cómodos los unos con los otros.


2. La Curva del Cambio o Curva "J" (fuentes: Elisabeth Kübler-Ross, Albretch, David Viney y otros)


Ver fuente (3)
Ver fuente (4)


Ver fuente (5) - Un excelente post- 

Las causas por las cuales se transita esta curva son muchas, pues cuando llegamos a un nuevo proyecto se vienen cambios como:
  • El nuevo proyecto (obviamente)
  • Conocer una nueva tecnolología
  • Conocer a mis compañeros
  • Conocerme interactuando con mis compañeros
  • Conocer un nuevo negocio
  • Conocer una nueva metodología
  • Conocer una nueva empresa y sus reglas
  • Conocer los nuevos sistemas
  • Conocer la forma de interactuar en esa organización.

Lo que nos demandará inevitablemente avanzar por esta "J" del cambio y desempeño.

y por último (aunque no sé si sea la última causa, puede que existan más)

3. La Zona de Reducción de Riesgos en TI  de Cockburn



Esta curva ya la habíamos discutido en otro post anterior - ¿Cuándo usar Ágil? o ¿Cuándo se Comienza a Generar Valor un Proyecto Ágil (4)? clic aquí - y observábamos que cuando un equipo supera la zona de adquisición de conocimiento la generación de valor fluye a ritmo constante, por lo tanto, aunque los equipos conozcan:

  • la metodología, 
  • el lenguaje de programación 
  • y la tecnología que están manejando, 
existe el conocimiento que no poseen y que directamente implica un esfuerzo como:
  • nuevas reglas de negocio
  • los sistemas con los que interactuarán
  • la interacción para la empresa en la que estan comenzando a trabajar (suponiendo que son proveedores, aun si son internos pero todos son nuevos)
Y es en consecuencia, natural que exista una fricción inicial para alcanzar rendimiento y puedan jugar bien como equipo scrum o como un equipo ágil.

Ahora, habrá mucha más fricción si:
  • la tecnología es nueva
  • es primera vez que trabajan como equipo
  • es primera vez que interactúan usando la metodología o framework de trabajo


Unas Cuantas Conclusiones

  1. Es inevitable pasar por la zona de baja productividad
  2. En mi experiencia, he observado que los equipos logran llegar a la Fase Normalización de Tuckman aproximadamente  entre 4 y 8 sprints - sprints de duración de dos semanas-, antes no. Si alguien tiene mejores datos al respecto agradecería mucho los compartiera. 
  3. El periodo de 4 a 8 sprints podría ser más largo pero he observado que los ciclos continuos de feedback aceleran el proceso de maduración, permitiendo avanzar rápidamente en la curva J - ver este post donde afirmo que Scrum es un modelo de Auto-Coaching de equipos http://www.lecciones-aprendidas.info/2018/08/scrum-como-modelo-de-auto-coaching.html -.
  4. Se requiere de un buen liderazgo situacional del Scrum Master para que este periodo sea cubierto de forma exitosa. - ver este post Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización http://www.lecciones-aprendidas.info/2015/11/como-ensenando-montar-en-bicicleta-como.html -
  5. La verdadera velocidad o capacidad del equipo debe considerarse después del ciclo de estabilización, o sea, después del quinto o noveno sprint según el caso.
  6. Recordemos que el Product Owner,  el Scrum Master y el Equipo de Desarrollo, son un equipo por lo tanto, todos están padeciendo los efectos de este inicio y acople.
  7. Luego de estabilizada la velocidad o capacidad del equipo, la forma de incrementarla poco a poco es:
    • promoviendo la excelencia técnica
    • no escribiendo código basura, apestoso o "crappy code"
    • removiendo la deuda técnica y haciendo refactors estratégicos
    • aplicando las prácticas ágiles de desarrollo (pair programming, tdd, propiedad colectiva del código, etc)
    • implementando las mejoras identificadas en las retrospectivas
    • tener retrospectivas exitosas que le permitan al equipo avanzar en la dirección correcta - ver post http://www.lecciones-aprendidas.info/2017/02/scrum-master-como-continuar-la-mejora.html
    • trabajar la felicidad del equipo


Cerrando, Qué recomiendo

  1. No es una buena estrategia estar armando y desarmando equipos, se pierden estos procesos de acople, un principio importante a aplicar llevarle proyectos a los equipos en vez de armar equipos para los proyectos, es muchísimo más productivo para todos.
  2. Recomiendo que al menos la mitad más uno de los integrantes del equipo sean entre Semi-senior y senior, esto acelera los procesos de formación de equipo y reduce considerablemente la creación de código basura debido a inexperiencia de los Juniors, pues los desarrolladores maduros le hacen mentoring a los nuevos - esto es de bastante importancia en equipos que desarrollan software - 
  3. Hacer consciente a las organizaciones que comienzan con scrum, o con cualquier marco ágil,  que sus equipos agiles no van a ser "super- ágiles" y "super productivos" por el simple echo de que los pongamos juntos, con un tablero lleno de post-it, Jira u otro software instalado, un Product Owner y un Scrum Master,  es cierto van a ser mejores que en cascada o tradicional, pero es un hecho las primeras velocidades son lentas, y se requiere de acompañamiento incrementarlas.
  4. Se recomienda hacer las proyecciones de cuando se va a entregar el producto luego de la fase de estabilización, antes no tiene sentido hacer proyección alguna, 
  5. Liderazgo situacional es clave en este tipo de procesos. Sugiero se revise esta colección de post Tips para Comenzar con un Equipo Scrum - http://www.lecciones-aprendidas.info/search/label/comenzando%20con%20scrum proporciona herramientas útiles en el proceso de maduración y estabilización de tu equipo.

Hasta acá este compartir. Bienvenido el feedback.

Saludos Ágiles

Jorge Abad.


Notas, Comentarios, Observaciones y Referencias

  1. Les recomiendo este artículo de Martín Alaimo - http://www.martinalaimo.com/es/blog/hacia-un-equipo-real - y la serie de "Hacia un Equipos Real" - http://www.martinalaimo.com/es/blog/tag/equipos-reales-.
  2. Explicación de la curva de Tuckman en este post:  Equipos Estables por sobre Pool de Recursos - http://www.martinalaimo.com/es/blog/equipos-estables
  3. Curva de Cambio - http://activaconocimiento.es/curva-de-cambio/
  4. Las fases que vivimos ante un cambio -https://elpais.com/elpais/2013/12/16/laboratorio_de_felicidad/1387150998_138715.html
  5. Falsos Positivos (agárrense que vienen curvas) https://wynwin.wordpress.com/2013/05/10/falsos-positivos/

domingo, septiembre 09, 2018

Próximos Entrenamientos en Scrum y Leading SAFe



Hola a todos

Les comparto los próximos entrenamientos que estaré facilitando:

Si tienes alguna inquietud no dudes en comunicarte a través de la zona de comentarios o al correo jorge.abad@gmail.com

Saludos Ágiles

Jorge Abad

miércoles, agosto 22, 2018

MiniManual para la Gestión por Valor