jueves, abril 19, 2018

[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? 
  • ¿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




martes, abril 17, 2018

Tweet: Agile no gestionar por alcance sino por valor

martes, abril 03, 2018

¿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í.