Freddie Mercury - Queen - y su definición de equipo (banda)

Hola a todos

Les comparto esta divertida entrevista a Freddie Mercury (vocalista de Queen), aprovechando que todos los estamos recordando por estos días.

Lo más interesante es la definición de banda (equipo) que tienen ellos, ¿les parece conocida?. Espero la disfruten

----

¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles? (o ¿Por qué no puedes contratar en alcance, tiempo y costo fíjo un proyecto ágil?)

Por:
Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)

Aunque en varios foros hemos compartido que contratar en Cascada (o tradicional, o con alcance, tiempo y costo fijos) un proyecto (o mejor, producto) ágil es completo dolor de cabeza para ambas partes, es como querer jugar rugby con las reglas del del fútbol, en este post, quisiéramos compartirte unas ideas claves de por qué no te conviene hacer esto tanto desde del punto de vista del Cliente como del Proveedor, vamos pues:

Problemas desde el punto de vista del Cliente

• El alcance no puede ser fijo en estos tiempos de alta disrupción (VUCA (1)) y es un error tratar de definir los requisitos a priori dada esta misma volatilidad(2) 
• El proceso de control de cambios (no te agregaría ningún valor)haría muy lenta las decisiones, y retrasaría el Time to Market, considerando que en ágil existe una continua repriorización y modificación de los requisitos en función del valor. 
• Tal vez (la verdad, muy seguramente) te obligues a construir lo innecesario. 
• Como la responsabilidad no es compartida, se genera una relación de competencia en vez de una relación de colaboración, impidiendo maximización del valor del producto. 
• Las estimaciones y costos con seguridad estarán inflados debido a la incertidumbre 
• Quemarás al proveedor y al equipo de trabajo, pues estos fallarán continuamente en sus estimaciones. 
• Los contratos tradicionales se basan en la desconfianza. Esto aumenta la incertidumbre y maximiza los riesgos. La incertidumbre y los riesgos nunca son buenos para el cliente, generan presión y desgaste. Se pierde el foco en lo que es realmente importante: el valor para la organización y la oportunidad. 
• Los planes se basan la percepción y no en la realidad. Lo que conduce a que haya una dedicación exclusiva a "cuidar" esos planes. Esto es desperdicio. Pérdida de dinero. Dinero del cliente. 
• La realidad es lamentable: con un contrato tradicional siempre o casi siempre hay desviación por sobrecostos, esto “hiere” mortalmente la confianza interna del cliente, es decir, entre las áreas involucradas. 
• Los continuos cambios pueden ocasionar modificaciones en las cláusulas en el contrato. Allí surgen roces entre las partes, proveedor y cliente. 

Problemas desde el punto de vista del Proveedor

Nota: este tipo de espantajos metodológico-contractuales por lo general se contratan bajo la siguiente forma: un alcance definido o que se define durante los primeros dos o tres meses y luego se hace una estimación que se parte en sprints.

• De entrada sabes que la estimación es fallida, que debes incrementar costos y tiempos y no tienes como justificarlo, y aunque lo justifiques el cliente no te creerá haciendo reducir costos y tiempo (pues el alcance lo dejan fijo) y exponiéndote a un riesgo financiero, reputacional o de penalidades. 
• Aunque estimes a priori el proyecto y ejecutes por sprint, te atrasarás debido a la incertidumbre de reinante en el mundo del software, incrementando la presión sobre el proyecto y la ejecución 
• Te la pasarás reunión tras reunión justificando por qué no estás cumpliendo el plan (sabiendo que trabajas en scrum con sprints) y tratando de reacomodar el plan 
• Los controles de cambio son un dolor de cabeza que no te permite realizar priorización por valor que le conviene más al cliente y al proyecto (producto) 
• Las métricas de seguimiento cascada aplicadas al proyecto (o producto) en ágil generan un desgaste pues no hacen match con las métricas de seguimiento ágil. 
• Quemarás a tu equipo tratando de ponerte al día con el cronograma de sprints comprometido al principio del proyecto.

Soluciones

• Contrata en ágil los proyectos ágiles (ver nuestro video sobre contratos ágiles - https://www.youtube.com/watch?v=872uF0dPYd8) 
• Pon cláusulas de terminación anticipada, que te sirvan cuando decidas no continuar con el cliente o con el proveedor según el caso. 
• En un contrato ágil nunca pongas el alcance fijo. 
• Si te preocupan los ANS o SLA, en Scrum tienes software funcionando cada dos semanas lo que permite validar si el proveedor está construyendo el producto de forma satisfactoria. 

Si tienes alguna otra disfuncionalidad a compartir, no dudes en hacerlo en la zona de comentarios


Saludos Ágiles

Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)

Referencias, comentarios, notas y aclaraciones

1. VUCA. Las siglas en inglés de Volatilidad, Incertidumbre, Complejidad, Ambigüedad. Más en https://hbr.org/2014/01/what-vuca-really-means-for-you
2. Radioactividad de los requisitos - La necesidad de un enfoque ágil en la industria del desarrollo de software - http://www.lecciones-aprendidas.info/2015/04/radioactividad-de-los-requisitos.html
3. Este artículo fue escrito a cuatro manos, y fue publicado en el Gazafatonario IT en http://www.gazafatonarioit.com/2018/11/por-que-no-debes-contratar-en-cascada.html

Algunos Tweets Importantes sobre Historias de Usuario

Stop worrying about writing perfect users stories. As @jeffpatton writes in User Story Mapping, stories are meant to be told, not written.

— Jim Constant (@TheAgilePO) May 28, 2014

---

"stories aren't a different way to write requirements, they're a different way to work!" @jeffpatton pic.twitter.com/cT91mB2ERe

— Andy de Vale (@andydevale) October 30, 2018

---

@jmbeas @jeffpatton @david_caicedo http://t.co/nZu7d99Va2http://t.co/pcRLrNfs48

Key point: User Stories are TOLD, not written.

— Ron Jeffries (@RonJeffries) May 23, 2015

---

Agile stories don't rely on the document as the primary mechanism for building shared understanding, they rely on the story telling. https://t.co/j735QrOCE9

— Jeff Patton (@jeffpatton) October 27, 2016

---

"We don’t need an accurate document, we need a shared understanding." - @jeffpatton

— Rich Rogers (@RichRogersIoT) April 18, 2018

---

As an author of the Agile Manifesto
I want that stupid story format to go away
So that people can get to the essence of user stories.

— Ron Jeffries (@RonJeffries) April 7, 2016

---

@keithb_b if your user story begins "As a", you haven't understood user stories.

— Ron Jeffries (@RonJeffries) October 1, 2016

De Colección: Algunas frases que sirven para el desarrollo de productos

"No hay nada más inutil que hacer eficientemente aquello que no debería haberse hecho en absoluto" [Peter Drucker]

— Lucho Salazar (@luchosalazarc) November 12, 2018

---

"La perfección no se alcanza cuando no hay nada más que añadir, sino cuando no hay nada más que quitar" Antoine de Saint-Exupéry

— Jorge Hernán Abad L. (@jorge_abad) November 13, 2018

Dos razones del cambio

“We generally change ourselves for one of two reasons: inspiration or desperation.”

― Jim Rohn

"Generalmente cambiamos por una de estas dos razones: inspiración o desesperación"

― Jim Rohn

 ----

#DeColección

“We generally change ourselves for one of two reasons: inspiration or desperation.”
― Jim Rohn

— Jorge Hernán Abad L. (@jorge_abad) November 17, 2017

Todos estamos jugando a ganar.

Una Reflexión

De las cosas que mas me han servido laboralmente (y hasta en el ámbito personal) en los últimos años, es comprender que TODOS SIEMPRE (es cierto, es una generalización) ESTAMOS JUGANDO A GANAR.

La clave es entender que la DEFINICIÓN DE GANAR de los otros, algunas veces es la misma nuestra, otras veces es no (y eso no es malo). Saber alinearse, saber entender o encontrar esa definición del otro, me ha ayudado a ser más empático y a generar mejores resultados donde hay más abundancia para las partes.

Esta habilidad me ha permitido ser mejor #influenciador y mejorar altamente la colaboración.

Saludos ágiles
Jorge Abad

Hangout ¿Cómo Contratar un proyecto ágil? (o filosofemos sobre contratos Ágiles)

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?

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

_

Hacer un producto/proyecto #Agile con un contrato tradicional (alcance, tiempo y costo fijos) es un dolor de cabeza para todos. Es como jugar fútbol con las reglas del rugby.

Tip: una de las tres restricciones debe liberarse, preferiblemente el alcance https://t.co/M2FkrzODN2

— Jorge Hernán Abad L. (@jorge_abad) October 24, 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.

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

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/

Próximos Entrenamientos en Scrum y Leading SAFe

Hola a todos

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

• Scrum Master - Octubre 20 y 27 - Ciudad: Medellín - Clic aquí para más información
• Leading SAFe (entrenamiento oficial) - Noviembre 3 y 10 - Ciudad de Medellín - Clic aquí para más información

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

MiniManual para la Gestión por Valor

MiniManual para la Gestión por Valor

1.¿Añade valor construir más alcance?
-si, construye más alcance y pon el siguiente hito lo más cerca posible y regresa a 1
-no, ¿por qué?
-Logramos el valor, resuelto el problema
-no, la hipótesis falló, no tiene sentido continuar#Agile

— Jorge Hernán Abad L. (@jorge_abad) August 23, 2018

Scrum Como Modelo de Auto-Coaching para los Equipos

Hola a todos

Hace unos días en una reunión de Ágiles Ecuador - en la que tuve la oportunidad de ser el facilitador de la Sesión de Migas de Pan(1)-, alguien sugería al cierre de la misma que para ser Scrum Master era necesario hacer un coach profesional como primer paso, y después de debatir un poco, decantábamos que no, que no era necesario, pues tanto un Scrum Master, un Agile Coach de Equipos o un Agile Coach Empresarial tienen más de mentor, de experto, de maestro, de líder, de entrenador de equipos, que alguien que a través de preguntas quiere acompañar a un individuo en su viaje de un estado a otro en su vida (y reconozco que este es un punto que aun no se termina de desarrollar en la comunidad ágil).

Pero también en esa discusión observábamos que un equipo que hace Scrum, tiene un ciclo de mejora continua que esta cuestionando constantemente tres ejes:

• La organización
• El equipo
• La persona que hace parte del equipo Scrum

Cíclicamente un equipo que hace Scrum, se enfrenta a su verdad - gústele o no - pues al principio en el Planning hacen una compromiso de lo que creen que van a construir y al final en la Review están mostrando lo que lograron a los Stakeholders y luego se van a la Retrospectiva con su resultado a filosofar que pueden hacer distinto para ser más exitosos el siguiente ciclo. Este ejercicio de:

• hacer una apuesta basados en su capacidad
• ver el resultado
• mostrar el resultado
• enfrentarse al feedback de sus stakeholders
• indagar por que se obtuvo el resultado
• proponer que mejorar internamente para ser más exitosos la próxima vez
• proponer que mejorar externamente para ser más exitosos la próxima vez

Termina cambiando a las personas, equipos y organizaciones.


Esta dinámica genera un circulo virtuoso transformador, pues:

• te va haciendo responsable de tus compromisos
• te hace revisar tus capacidades y buscar nuevas
• te invita a tener mejores interacciones con tus compañeros para tener éxito
• te invita a cuestionarte, cuestionar respetuosamente a los otros y cuestionar a la organización en la que estas inmerso

En definitiva, no te puedes quedar quieto ante un marco que cada semana, dos semanas o máximo un mes te muestra tu verdad tal cual es, o cambias, o cambias (así lo he visto funcionar cantidad de veces)

Scrum por sus ciclos de PHVA(2) continuos, termina cambiando al Equipo, al Scrum Master y al Product Owner, y al final de su viaje en la construcción del producto terminan siendo personas completamente distintas  y quienes hayan vivido este viaje sabrán darme la razón.

Para cerrar es importante aclarar que no solo Scrum puede darte este beneficio, cualquier modelo de trabajo que en ciclos cortos (de no más de un mes) nos esté enfrentando a la verdad y nos esté retando a salir de nuestra zona confort generará resultado similares.

Bonus Track

Ahora, cuando alguien me pregunta ¿que tiene que hacer para ser Agile Coach? lo invito a que comience este camino con corazón (3) siendo Scrum Master - que es el Agile Coach del equipo Scrum-, y enfrente allí sus verdades, junto con su equipo, y luego de al menos cuestionarse, cuestionar, y retar durante un buen tiempo determine hacia donde seguir avanzando.

Bueno, hasta acá esta corta reflexión y compartir.

Si tienes algún comentario bienvenido el feedback en la zona de comentarios

Saludos Ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Actividad que le aprendí de mi gran amigo Carlos Gil
2. El ciclo Planear - Hacer - Verificar - Actuar, promovido por E. Deming

3."...Cualquier cosa es un camino entre cantidades de caminos. Por eso debes tener siempre presente que un camino es sólo un camino. Si sientes que no deberías seguirlo, no debes seguir en él bajo ninguna condición. Para tener esa claridad debes llevar una vida disciplinada.Sólo entonces sabrás que un camino es nada más un camino, y no hay afrenta, ni para ti ni para otros, en dejarlo si eso es lo que tu corazón te dice.

Pero tu decisión de seguir en el camino o de dejarlo debe estar libre de miedo y de ambición. (...) Mira cada camino de cerca y con intención. Pruébalo tantas veces como consideres necesario.

Luego hazte a ti mismo, y a ti solo, una pregunta: ¿Tiene corazón este camino?

Si tiene, el camino es bueno; si no, de nada sirve. Todos los caminos son lo mismo, no llevan a ninguna parte. Son caminos que van por el matorral. Ningún camino lleva a ninguna parte, pero uno tiene corazón y el otro no..." Uno hace gozoso el viaje; mientras lo sigas, eres uno con él. El otro te hará maldecir tu vida. Uno te hace fuerte; el otro te debilita."

El problema es que nadie se hace la pregunta, y cuando por fin se da cuenta de que ha tomado un camino sin corazón, el camino está ya a punto de matarlo.Un camino sin corazón nunca se puede disfrutar. Hay que trabajar duro tan sólo para tomarlo. En ese punto pocas personas pueden parar a pensar y dejar el camino...

En cambio, un camino con corazón es fácil: no te hace trabajar por tomarle gusto. Para mí existe solamente el viajar por caminos con corazón, en cualquier camino que pueda tener corazón. Por ahí viajo, y el único desafío que vale la pena es atravesarlo en toda su longitud. Y por ahí viajo, buscando, buscando, sin aliento". (“Las enseñanzas de Don Juan” de Carlos Castañeda.)

Hablemos de Deuda Técnica “Cómo la Deuda Técnica puede acabar tu proyecto ágil”

Hablemos de Deuda Técnica “Como la Deuda Técnica puede acabar tu proyecto ágil” from Jorge Hernán Abad Londoño

Un Método Adicional de División de Historias de Usuario: Criterio de Equipo o Hasta Acá Llegamos

Hola a todos

Existe un método adicional de división (splitting) de historias de usuario al presentado en Leído y Recomendado: División de historias de usuario -clic aquí- y es el usado por el Criterio del Equipo o al que yo llamo "Hasta acá llegamos" y la situaciones en las que he observado que se presenta son las siguientes:

Situación 1: El equipo observa una historia de usuario muy grande

• El Product Owner (PO) explica una historia de usuario
• El Equipo la estima y la ve muy grande (ver post) o muy riesgosa,
• Entre PO y Equipo se estima hasta donde llegan en esa historia (dependiendo si la dividen por valor para el Sprint o Riesgo) y si el resto será en otra historia de usuario que posiblemente se construya en este sprint o se decida realizar el siguiente.

Situación 2: El product backlog esta casi listo y se quiere añadir una historia de usuario

• Se tiene el sprint backlog casi listo, queda un poco de capacidad libre para una nueva historia de usuario.
• El PO explica una historia de usuario
• El Equipo observa que no hay capacidad para asumir esta historia de ese tamaño y las subsiguientes historias también parecen ser de tamaños similares o superiores.
• El Equipo con el PO dividen la historia de forma que se logre incluir lo que más genera valor en el planning actual y se deja para otro sprint el resto (pero en una nueva historia).

Espero haya sido útil este corto compartir.

Saludos ágiles

Jorge Abad

Leído y Recomendado: Patrones de División de Historias de Usuario o Cómo Dividir una Historia de Usuario

Hola a todos

Como alguno de ustedes saben, muchas veces uso mi blog como referencia cuando comparto entrenamientos y charlas, es mi repositorio oficial en el que recopilo y comparto información, conocimiento y experiencias.

Quiero en este post dejar referencia del interesante artículo que comparto constantemente en los entrenamientos sobre división de historias de usuario publicado en Agileforall.com.

Espero les sea de gran utilidad como lo ha sido para mi.

Link del post -1: How to Split a User Story - Clic aquí
Link del post -2: New Story Splitting Resource - Clic aquí
Link del poster en pdf en inglés: clic aquí.
Link del poster en pdf en español:clic aquí.

Link de backup por si los anteriores no funcionan - inglés: clic aquí.
Link de backup por si los anteriores no funcionan - español: clic aquí.

Saludos ágiles

Jorge Abad

Dos ideas sobre Agile

Dos ideas

- No seas ilus@, #Agile no va a resolver tus problemas, lo que si va a hacer es a evidenciarlos más rápido.

- Si tu gestión es basada en la falta de transparencia, no uses #Agile pues rápidamente te pondrá en evidencia.

— Jorge Hernán Abad L. (@jorge_abad) August 7, 2018

Datos, Hechos y Beneficios de Agile+DevOps en una Empresa Pública de Colombia

Hola a todos

Aunque cada vez es menos frecuente la incredulidad hacia Agile, siempre es bueno contar con casos de éxito y en especial con una colección de métricas capturadas en un entorno empresarial, para compartirlas con personas y empresas que se están acercando al concepto.

A continuación les comparto este Tweet de Claudia Toscano quien trabaja en área de TI de Empresas Públicas de Medellín (empresa con sede en Medellín - Colombia), con una hermosa colección de métricas como resultado de aplicar Agile y DevOps en su entorno.

Aunque parece obvio, importante resaltar que corresponden a datos de una Empresa Pública.

---

Cuando son ellos quienes te buscan para trabajar con esos marcos ágiles y automatizar pruebas y despliegues, sabes que hiciste bien la tarea! #epmagile @ricardorq85 @sperezj @RoseRestrepoV @EPMestamosahi @kleer_la @Intergrupo @10pines @techandsolve @CeibaSoftware pic.twitter.com/HJyodXFDAP

— Claudia Toscano Varg (@claudytoscano) July 31, 2018

---

---

---

Nota Importante: Si como empleado público (o empleado privado) insistes en contratar proyectos de desarrollo de software en cascada (waterfall, o tradicional, es decir: una fase larga de levantamiento de requisitos, luego otra de desarrollo, luego una tortuosa de pruebas y por fin una entrega tardía y un contrato con alcance, tiempo y costo fijo) es muy probable que estés incurriendo en algo que en Colombia le llamamos Detrimento Patrimonial - es decir, estas haciendo mal uso de los recursos del Estado - o de tu organización - y estas probablemente derrochando probablemente un valor cercano al 50% del valor del contrato-, pues existen numerosos estudios que demuestran que hacer proyectos en cascada genera desperdicios en funcionalidades que no serán usadas cercanos al 50%. Anexo resultados de un estudio muy conocido "el Manifiesto del Caos  del 2013(ver Página 6)":

Te comparto algunos links que aun funcionan:

• http://fliphtml5.com/scht/mwde/basic
• https://es.scribd.com/document/198550543/Chaos-Manifesto-2013

Saludos ágiles

Jorge Abad

[Preguntas y Respuestas] ¿En mi producto no hay un MVP de quien es la responsabilidad de que este exista?

Hola a todos

Hace poco publiqué en LinkedIn una pregunta (ver links al final):

"¿Soy #ScrumMaster y no hay un MVP (producto mínimo viable) definido para el producto de quien es la responsabilidad de que este exista? 

Del SM, muchas veces el PO es la primera vez que ejerce el rol, y de pronto ni ha sido capacitado, mi deber como sm es ser el Coach del PO y enseñarle a como ser un gran PO, priorizar el product Backlog por valor, encontar el MVP, escribir historias de usuario etc. "

en su clarificación se compartieron varios aprendizajes que han servido

• El Scrum Master es el experto en el marco
• El Scrum Master esel Agile Coach del Product Owner y del Equipo
• El Scrum Master como experto y coach si observa que su Product Owner no entiende ciertos conceptos, lo formará y apoyará hasta que este se haga responsable de los mismos
• La guía oficial -scrumguides.org - presenta al Scrum Master a estar al servicio de Product Owner de la siguiente forma:
• Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el equipo Scrum de la mejor manera posible;
• Encontrar técnicas para gestionar la Lista de Producto de manera efectiva;
• Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista de Producto claros y concisos;
• Entender la planificación del producto en un entorno empírico;
• Asegurar que el Dueño de Producto conozca cómo ordenar la Lista de Producto para maximizar el valor;
• Entender y practicar la agilidad; y,
• Facilitar los eventos de Scrum según se requiera o necesite
• Se invitaba a que los Scrum Masters fueran proactivos en vez de esperar que sus Product Owners vengan preparados y listos con todas las técnicas de facilitación y gestión de producto, los acompañaran y formaran hasta que estos fueran Product Owners Grandiosos (recomiendo este post Guía Supernumeraria para un Dueño de Producto Virtuoso - de Lucho Salazar- clic aquí-)
• Este post tambien aplica para la pregunta: ¿En mi producto no hay un Plan de Relaeases de quien es la responsabilidad de que este exista?
• Es probable que un producto con salidas frecuentes a producción, cada fin de sprint o varias veces durante el sprint, no requiera un plan de releases,

Bienvenido el Feedback

Saludos Ágiles
Jorge Abad

---

Link de la conversación en Linked in: https://www.linkedin.com/feed/update/urn:li:activity:6412122454839357440

Link de la conversación en Facebook: https://www.facebook.com/jorge.abad/posts/10160545277655788

Aclarando Sobre Historias de Usuario

Hola a todos

Existe una página de Facebook que pone excelentes temas de cuestionamiento sobre testing llamada "Señor Tester" - clic aquí para verla -, lo cierto es que esta semana publicaron algo que comenté pues hace parte de los malentendidos relacionados con las historias de usuario.

A continuación les comparto el post y mi respuesta

Saludos Ágiles 

Jorge Abad

------------------------

El Post: https://www.facebook.com/elseniortester/photos/a.863366253809076.1073741828.826564797489222/1457673961044966/?type=1&theater

mi respuesta fue:

Esta es la transcripción

genial...es lo mejor que puede suceder.. y observo varias cosas:

• las historias de usuario no se envían, se explican en el planning
• entre más ambiguas mejor...pues implicará que el #ProductOwner, se haga entender por todo el equipo
• Al tester no lo estan invitando al planning mal #Agile, mal #Scrum o #FrAgile -- tiene que estar allí con todo el equipo, hace parte del equipo
• te recomiendo este post   - Algunas Ideas Claves sobre Historias de Usuario - clic aquí..-
• las historias de usuario NO SON ESPECIFICACIONES.. su creador argumenta que si hubiera querido que fueran especificaciones, se llamarían ESPECIFICACIONES DE USUARIO, pero se llaman historias por que deben ser contadas y explicadas
• Al Señor Tester  le esta tocando un equipo que hace mal #Agile, mal #Scrum o #FrAgile

un abrazo Señor Tester  y espero algún días hagas parte de un verdadero equipo ágil

Dedicación del Scrum Master y el Product Owner en el tiempo

Hola a  todos

Hace algún tiempo compartí este artículo "El objetivo de Scrum Master, NO PUEDE SER, dejar de ser necesario para el equipo", con su link hacia la referencia original en inglés "The goal of a Scrum Master is NOT to make herself unneeded", el punto es que noto que sigue siento cierto, la experiencia me lo sigue confirmando, pero como dato adicional quiero compartir hoy una gráfica atribuida a Mike Cohn sobre la dedicación del PO y el SM en el tiempo.

¿De qué factores corresponderá esa inflexión en la curva?

• Del Scrum Master
• Del Product Owner
• De la madurez del Equipo
• De la estabilidad del equipo
• Del tiempo (8meses, un año, dos años)

No hay respuestas definitivas o contundentes, como siempre nos tocó recurrir a "Inspección y Adaptación"

Saludos Ágiles

Jorge Abad

Unos tweets sobre agile y management

Un mensaje que continuamente comparto:

"Gerente si en el pasado tu forma de generar valor era controlar gente,en #Agile la gente se autocontrola y es autónoma, por lo tanto debes encontrar otra forma de aportar a la organización"#Agileleadership

— Jorge Hernán Abad L. (@jorge_abad) July 25, 2018

---

Segun como termines esta frase te diré que tan #agile eres:
"Lo que no se mide no se...
.
.
.
.
.
.
.
.
.
,
.
.
.
.
.
.
...Mejora"

Aclaro, el propósito en #Agile no es el control, sino la mejora continua que nos hace inalcanzables.#agileleadership

— Jorge Hernán Abad L. (@jorge_abad) July 25, 2018

---

"No se puede gestionar lo que no se ve" - Jim Benson

De Colección: Evolución (niveles, o tipos) de Product Owner

Hola a todos

Buscando una información relevante respecto al Product Owner, quisiera compartir estos niveles, tipos, evolución del PO y el beneficio que generan, que me encontré en este excelente artículo -http://roneringa.com/evolution-product-owner/ -

Saludos ágiles

Jorge Abad

Desperdicio Generado por la Pérdida de Contexto o "Switcheo" entre Proyectos

Hola a todos

Hay cosas sobre las cuales no se puede dejar de insistir, y esta es una de ellas el multitasking, pérdida de contexto o switcheo constante entre proyectos.

La dejo por acá para que la usen de referencia.


Saludos ágiles

Jorge Abad

Tweet: La combinación Agile DevOps ya no es opcional

La pregunta ahora NO es ¿si la empresa hace o no Agile-DevOps?
la pregunta es ¿que tan bien lo está haciendo y cómo lo va a seguir
mejorando?

La combinación #Agile #DevOps ya no es opcionalhttps://t.co/FE2Fud0gAO

— Jorge Hernán Abad L. (@jorge_abad) May 4, 2018

Presentación: Las Cinco Disfunciones de los Equipos y el Miembro de Equipo Ideal

Las Cinco Disfunciones del Equipo y el Miembro de Equipo Ideal from Jorge Hernán Abad Londoño

[Scrum] Una queja común en algunos Scrum Masters: Mi Product Owner no es bueno

Hola a todos

En sesiones de mejora con Scrum Masters (SM) con frecuencia me encuentro con las siguientes quejas acerca del Product Owner (PO):

• no tiene tiempo para el equipo
• no escribe bien las historias de usuario 
• no está priorizando el product backlog
• no hay un plan de releases
• no se tiene un Producto Mínimo Viable (MVP).
• no se tiene una herramienta de seguimiento de releases como un Burn Up Release (por ejemplo)
• entre otras preocupaciones

Es allí donde les solicito que me compartan que saben del rol del Scrum Master y me responden palabras más palabras menos, lo que que está a continuación (-que se interpreta en la guía oficial de Scrum- ):

Luego de esto, comienzo una ronda de preguntas y respuestas de más o menos este estilo:

• ¿Quién es responsable de que se tengan buenas historias de usuario, el P.O., el Team o el SM? 
• Rpta/. Es el SM como experto del marco es el encargado de garantizar que el equipo tenga los ítems de backlog adecuados para trabajar, y es su deber como coach del PO de enseñarle y verificar las historias de usuario para que estas cumplan con un estándar mínimo de calidad (las tres CCC e INVEST). ( leer tambiém :El Product Owner "NO" Necesariamente Escribe las Historias de Usuario o Ítems de Backlog - clic aquí)
• ¿Quién es el responsable de que no se tenga un buen Product Backlog, Plan de Releases, Producto Mínimo Viable (MVP), un Burn Up Release?
• Rpta/. Pareciera que inicialmente es el PO, pero similar al punto anterior, el SM como coach del PO debe enseñarle y ayudarle a mantener los artefactos de scrum, hasta que estos sean los adecuados para construir un producto exitoso.
• ¿y que podríamos hacer con respecto a la falta de tiempo del PO?
• Rpta./. El SM debe buscar como lograr más tiempo de la organización para el PO - al menos medio tiempo-, o encontar la forma de que esto se resuelva con otro PO, o un PO Proxy, pero recordemos que el SM es un agente de cambio para la organización y es responsable de que la organización comprenda como funciona Scrum y los requisitos para que sea exitoso.

Es importante comprender que el Scrum Master es el responsable de Framework de Scrum, debe trabajar por su funcionamiento exitoso, que debe convertirse en Responsable en vez de Víctima,  haciendo que las cosas pasen, si su PO, equipo o algo no funciona pues debe moverse para que las cosas sucedan.

Hasta acá este corto compartir

Saludos ágiles

Jorge Abad

Tweet: Agile no gestionar por alcance sino por valor

Entre los grandes cambios que introduce #Agile en una organización es pasar de

La Gestión del Alcance a la Gestión del Valor

Este "simple" cambio de enfoque:
-reorganiza equipos
-cambia métricas
-elimina desperdicios
-conecta más a las personas
-aumenta la felicidad

— Jorge Hernán Abad L. (@jorge_abad) April 17, 2018

Leído y Recomendado: Una petición cara a cara es 34 veces más efectiva que por correo electrónico

Un excelente ártículo del Harvard Business Review


https://www.hbr.es/redacci-n-empresarial/568/una-petici-n-cara-cara-es-34-veces-m-s-efectiva-que-por-correo-electr-nico -clic aquí-.


Saludos

Leído y Recomendado: Por qué la evidencia no logra cambiar lo que pensamos

Excelente artículo


http://www.perfil.com/elobservador/por-que-la-evidencia-no-logra-cambiar-lo-que-pensamos.phtml 



Saludos

¿Cómo desbloquear el miedo de tu cliente hacia la Agilidad? o ¿Cómo vender la Agilidad?

Hola a todos

A continuación les comparto una conversación que puede ayudar a desbloquear los miedos hacia la agilidad en tu interlocutor, ya sea PMO, Gerente, Director o Vicepresidente de IT, o alguien similar:

- [Promotor de la Agilidad]¿Cuánto del software que crees que actualmente y/o produces es usado?
- [Cliente] (Por lo general responde) entre el 50 % al 60%
- [Promotor de la Agilidad] El número generalmente es del 50% o menos (muestras como el Principio de Pareto también se cumple en Software(1)), pero que implica eso:

• que el 50% del tiempo del ultimo año lo pudiste no haber trabajado y el resultado sería el mismo,es decir, se pudo haber trabajado 6 meses o solo medio tiempo y el resultado obtenido es el mismo.
• al menos el 50% de tu dinero fue desperdiciado
• que te esta pasando lo contrario a lo que querías controlar con tus contratos y fue construir lo que no era.
• que el control predictivo no ha servido y ha generado un 50% de desperdicio (una de las razones es la inestabilidad actual de los requisitos (2))
• que tuviste al menos 50% de reuniones innecesarias de requisitos, 50%  de software en el servidor (si no es más) que no funciona,  50% de pruebas innecesarias, 50% de reuniones de aceptación y pruebas UAT que no era necesarias.
• que ese 50% de desperdicio es costo y tiempo de oportunidad que estas dejando de ofrecer a tus clientes externos e internos por hacer cosas que no servían.

-[Promotor de la Agilidad] por lo tanto en ágil tienes

• Software de valor cada dos semanas 
• Transparencia
• Si el proveedor no da la talla, a lo sumo se perdió dos semanas o máximo un mes
• puedes parar cuando quieras, o cuando una linea adicional de código no genere el ROI que compense su creación.
• Llegas más rápido a la solución, no porque la gente codifique más rápido, sino porque construyen menos desperdicio, implicando llegar más pronto a la solución buscada
• Liberas capacidad operativa que puede ser usada en innovación o en mejora operativa.

-[Promotor de la Agilidad] Si lo deseas comenzamos con un piloto pero debemos generar las condiciones que funcione la agilidad:

• Acompañamiento en el proceso, pues no puedes gestionar ágil bajo la misma mentalidad de cascada o tradicional
• Un Product Owner al menos un 50% del tiempo con el equipo
• Un contrato ágil para el proveedor, o al menos tiempo y materiales.
• Unas métricas de seguimiento ágil distintas a las de cascada
• Un piloto con condiciones para ser exitoso (3)
• Ambientes de desarrollo, pruebas lo más parecidos a producción y listos desde el inicio del primer sprint
• Un equipo de desarrollo competente
• Liberarse de los ANS o SLA, pues en Ágil no tienen mucho sentido (4)

-[Cliente] ¿Pero es que me han dicho que ágil es más costoso que cascada?

-[Promotor de la Agilidad] Pues sino te ha parecido muy costoso construir el 50% o más de software desperdicio durante los últimos años, no te va a doler hacer agilidad, además a cascada ya le has dado muchas oportunidades y en ocasiones no has ni entregado el proyecto, ¿por qué no te das el lujo de hacer bien ágil y ver que resultados obtienes?

-[Promotor de la Agilidad] ¿Cuando comenzamos?

Cerrando

La verdad no fue tanto un diálogo, fue más un monólogo, pero espero encuentres en este post elementos para ayudarte avanzar hacia la agilidad con tu interlocutor.

Bienvenido el feedback y éxitos en tu intención.

Saludos ágiles

Jorge Abad

Referencias

1. Pareto se cumple en software, clic aquí 
2. Los requisitos son más inestables hoy que en el pasado. clic aquí
3. Condiciones para selección del proyecto piloto, clic aquí.
4. Sobre RFP, ANS o SLA para desarrollos ágiles y otras perversiones, clic aquí.

¿Cuándo usar Ágil? o ¿Cuándo se Comienza a Generar Valor un Proyecto Ágil (4)?

Hola a todos

Hace un tiempo vi el excelente video de Agustín Villena - LKES17: Agustin Villena - Alineamiento, flujo y exploración (clic aquí) - recomiendo verlo con papel y lápiz, - por allá en el minuto 16:00-  clic aquí-, comparte la siguente gráfica de Alistair Cockburn.

Develop for business value once risks are down (1)

Donde el mensaje clave es: "Antes de comenzar a generar valor debes bajarle el riesgo a tu proyecto"

Es obvio sino tu proyecto, producto o iniciativa estará torpedeado por impedimentos, retrasos, problemas, desconocimientos, complicaciones técnicas, etc., cayendo en una zona de mucha fricción y poca velocidad en el desarrollo y en consecuencia es difícil generación de valor. Es por eso que también que dentro de las sugerencias para realizar un piloto en ágil se sugiere que la tecnología sea conocida y dominada por el equipo (2).

Ahora también,  lo presenta el articulo de Alistair (1) en el apartado "Don’t confuse knowledge acquisition with BDUF -Big Desing Up Front(3)", es probable que debas asumir una velocidad baja de tu equipo mientras logran:

• entender mejor la arquitectura
• resolver dependencias
• realizar pruebas de concepto
• comprender mejor los frameworks

Y luego de esta zona, si ganar velocidad en la zona de generación de valor.

Hasta acá este cortísimo compartir

Saludos ágiles
Jorge Abad

Referencias, Notas, Aclaraciones y Comentarios

1. Design as Knowledge Acquisition by Alistair Cockbur - clic aquí- .
2. Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos. - clic aquí -.
3. Big Desing Up Front: the old habit of sitting at the desk and drawing up a big, fancy, full-scale design (BDUF = “big design up front”) (1)
4. Cada vez más me alejo del concepto de Proyecto Ágil, podria cambiar este título por ¿Cuándo se Comienza a Generar Valor en la Construcción de un Producto de Forma Ágil?

Un tweet de un grande - R.I.P. Mike Beedle - Ágil no Cura la Incompetencia

✅ Agile doesn’t cure INCOMPETENCE.

You can coach teams to be more engaged and collaborative, but NO Agile framework, method, or mindset can save you from BLATANT FAILURE if your development team is INCOMPETENT in basic engineering practices.

Technical excellence is a MUST!

— Mike Beedle (@mikebeedle) March 21, 2018

Sobre RFP, ANS o SLA para desarrollos ágiles y otras perversiones

Hola a todos

En el medio, cuando hablamos con otros agilistas sobre la forma que las organizaciones están abordando la contratación de proyectos ágiles nos encontramos con RFP (Request For Proposal - Solicitudes de Propuesta) donde existen cláusulas, penalidades y ANS (acuerdos de niveles de servicio) como:

• El equipo deberá mejorar un 1% cada sprint su velocidad 
• Ganará el RFP el proveedor que proponga el menor tamaño de sprint 
• Ganará el RFP  el proveedor que proponga menos sprints
• Ganará el RFP el que haga historias de usuario en menos tiempo

Lo cierto es que venimos acostumbrados a penalizaciones y a la desconfianza de cascada, (-obvio nadie salía ganando, el producto no era el esperado, al igual que la fecha y el costo no se cumplían, es un caos por donde se mire -), en donde se generaban clausulas como:

• deberá reducir el porcentaje de defectos proporcionalmente en sus requerimientos
• por día de demora en la fecha de entrega deberá pagar $/día (y he visto proyectos donde la suma de la penalidad es tal que el proyecto termina valiendo cero pesos)
• Por cada error en producción se descontará $xx.xxx.xxx
• entre muchas otras cosas igual o peor de dolorosas donde el proveedor se acomodaba (cobrando más costoso - en el mejor de los casos-, o más barato) pues le interesaba conservar el cliente.(ver este post ¿Compras / vendes /licitas proyectos problemáticos de software? – Un pequeño deja vu - clic aquí)

Por lo tanto, es probable que quien este al frente de contrataciones de proyectos ágiles

• Esté mal asesorado
• No tiene conocimiento o entendimiento de ágil -no tiene que tenerlo, en algún momento yo no lo tuve- y en su buena voluntad cree que poniendo restricciones similares a la de cascada podrá "controlar" el proyecto (cosa que tampoco ocurría en cascada - pero que será artículo de otro post- ).

Lo que se observa en este caso es que se esta tratando de resolver un problema nuevo bajo un paradigma mental anterior y que no aplica para este nuevo contexto, y es allí donde se requiere de buen acompañamiento.

Dado lo anterior, cuales serían mis observaciones al clausulado del principio del artículo.

Clausula o ANS propuesto Observaciones el equipo deberá mejorar un 1% cada sprint su velocidad  Implica que la mejora un año deberá mejorar 48% (y eso que no apliqué la formula del interés compuesto) más de alcance al final del año si consideramos sprints de dos semanas(y en dos años del 96%). esto es insostenible, Lo que va a lograr es que las historias de usuario cada vez le pongan más tamaño. (obtienes lo que mides) O si se le hace auditoría las estimaciones de las historias de usuario (que es lo que menos valor genera, auditar estimaciones) terminará agotando al proveedor y dejará de ser negocio para el proveedor continuar con ese cliente pues no es rentable, ni demostrable ese ritmo sostenido de mejora. Ganará el RFP el proveedor que proponga el menor tamaño de Sprint El tamaño del sprint no implica absolutamente nada, se recomienda 2 semanas, equipos con mucha experiencia tienen sprints de 1 semana, y otros trabajan con kanban, pero es el contexto el que da el tamaño del sprint. Es mu probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas partes que ágil no sirve. Ganará el RFP  el proveedor que proponga menos sprints Es una orientación puramente hacia cascada y creer que se puede definir el alcance a priori en agile (aun en cascada) es falso.  Similar al anterior, es muy probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas que ágil no sirve Ganará el RFP el que haga historias de usuario en menos tiempo Las historias de usuario son irregulares, aunque se puede hacer partición de ellas no es posible garantizar un tamaño, y aunque se desarrolle más rápido algunas no es garantía de que todas van a ser así. Similar al anterior, es muy probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas que ágil no sirve

¿Cómo resolver esto?

• Opción 1: Prueba de Concepto

Una posible forma de saber con que proveedor quedarse es darle la oportunidad de ejecutarun proyecto en ágil , que ejecute varios sprints (2, 3, o 4 sprints)y si:

• tiene buen manejo de la metodología
• si equipo esta preparado y experimentado
• tiene gestión de la deuda técnica
• tiene prácticas técnicas
• su scrum master es preparado y con experiencia
• entregan software funcionando cada dos semanas

Continuar con el, sino detenerse y entregarle el proyecto otro proveedor.

¿Pero perdiste como cliente? No, ganaste conocimiento y al menos quedaste con software funcionando (cosa que no quedaba en cascada).

• Opción 2: Referencias

Otra opción es visitar referencias de clientes de ese proveedor y validar con un experto en ágil las experiencias y aplique las mismas condiciones de la opción 1, sino funciona terminar el contrato.

Lecturas Recomendadas

Recomiendo para la mejor comprensión y ayuda estos dos post

• Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos.(parte 2) -clic aquí- 
• Hablemos sobre Contratos Ágiles - clic aquí -

Bienvenido el feedback

Saludos ágiles
Jorge Abad