martes, julio 31, 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.










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:

Saludos ágiles
Jorge Abad



miércoles, julio 25, 2018

[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

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

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

martes, julio 24, 2018

Unos tweets sobre agile y management









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

domingo, julio 22, 2018

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

martes, julio 10, 2018

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