Este blog comparte estrategias y aprendizajes sobre desarrollo de software, marcos, metodos y metodologías ágiles como Scrum, Kanban y XP, con un enfoque en escalamiento ágil y Business Agility. Su propósito es ayudar a profesionales de la gerencia de proyectos y productos a mejorar sus procesos y promover la experimentación como motor de innovación, facilitando su adaptación en entornos empresariales cambiantes.
sábado, abril 28, 2018
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?
- 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.
Hasta acá este corto compartir
Saludos ágiles
Jorge Abad
martes, abril 17, 2018
Tweet: Agile no gestionar por alcance sino por valor
Entre los grandes cambios que introduce #Agile en una organización es pasar de
— Jorge Hernán Abad L. (@jorge_abad) April 17, 2018
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
jueves, abril 05, 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
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
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.
- 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.
- 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
- Pareto se cumple en software, clic aquí
- Los requisitos son más inestables hoy que en el pasado. clic aquí
- Condiciones para selección del proyecto piloto, clic aquí.
- Sobre RFP, ANS o SLA para desarrollos ágiles y otras perversiones, clic aquí.
Suscribirse a:
Entradas (Atom)