Leído y Recomendado: La historia de las historias de usuario por Lucho Salazar

Hola a todos

Les comparto este post de colección de mi gran amigo Lucho Salazar


La historia de las historisa de usuario - http://www.gazafatonarioit.com/2020/04/la-historia-de-las-historias-de-usuario.html

Notas del Meetup - [Web] Mapa mental de la guía de Scrum

Hola a todos

A continuación les compartimos el video y el resultado de las diferentes preguntas realizadas durante el meetup de ÁgilesColombia sobre el mapa mental de la guía de scrum.


Saludos Ágiles

Jorge Abad y Lucho Salazar

https://www.linkedin.com/in/jorgeabadl/ | https://www.linkedin.com/in/luchosalazar/

https://twitter.com/jorge_abad | https://twitter.com/luchosalazarc

---

La Guía de Scrum 2017 - En Mapa Mental

Hola a todos

La Guía de Scrum, la oficial, la publicada en https://scrumguides.org/, y en su versión en español para suramérica en 2017 https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf  traducida por mi estimado amigo Lucho Salazar, es un trabajo de sus creadores Jeff Sutherland y Ken Schawber de más de 20 años sobre ella.

Es bastante rica en conceptos, prácticas y sugerencias, fuera de ser muy, pero muy resumida.

Muchas veces al hacer una lectura de la misma, no somos conscientes de la cantidad de información allí depositada, y como nos pasa a muchos, cada vez que vamos a buscar un concepto, nos encontramos con perlas ocultas a nuestros antiguos ojos desprevenidos (los ojos del pasado) o tal vez sin el conocimiento para entender lo allí descrito, (me decía mi amiga Paola Becerra,  el ojo ve lo que es capaz de interpretar).

Bueno, con el fin de decodificar un poco la guía, me he animado a ponerla en formato de mapa mental.

Mapa Mental - Capítulos

Mapa Mental - Capítulos y Subcapítulos

El ejercicio no fue muy estricto desde las recomendaciones para crear mapas mentales, pero si con miras a ubicar fácilmente conocimiento clave.

Mapa Mental Completo - (lo sé, no se ve nada, pero es para que te hagas una idea de lo extenso del mapa)

De igual forma, he marcado en color verde y con (*) el texto relevante o las perlas ocultas a mis ojos del pasado.

Descárgalo y Úsalo

A continuación, pongo a su disposición varios formatos de descarga y visualización

• Descargar PDF - aquí  (es el más sugerido debido al tamaño, debes descargar y abrir desde un navegador web, como: Chrome, Edge, o Firefox, etc)
• Word - aquí
• PNG Aqui
• SVG - aquí

Espero que esta decodificación les sea tan útil como lo fue para mí, en este entendimiento y reestudio de la guía.

Disfruten las perlas (las que estan con asterisco (*) y en verde)

Saludos ágiles

Jorge Abad

Conversaciones del Scrum Master según la Madurez del Equipo

Hola a todos

Dentro de las charlas y acompañamientos que realizo a Scrum Masters y Agile Coaches, noto que muchos no conocen lo que se llama el liderazgo situacional, este fue propuesto por Hersey y Blanchard, y en el se explica que de acuerdo a la madurez del equipo, es la forma de delegar y empoderar  del lider (recomiendo ver (1)).

El Scrum Master es un lider servicial, que va llevando al equipo de desarrollo a ser cada vez mejor y más autoorganizado, para ser exactos la guía reza, en la parte del Scrum Master al servcio del equipo de Desarrollo, este debe  

"Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional" (2)

Por lo tanto, según la madurez del equipo se darán diferentes conversaciones que los Scrum Masters tendrán con sus equipos, a continuación un ejemplo:

• Equipo en Formación - Conversación tipo: Comando y Control
• "-Para que nos vaya mejor con los reportes de seguimiento que nos están pidiendo, vamos a dejar registro de la cantidad de horas que nos estamos gastando logrando una aprobación. ¿Quién se hace cargo? o sino, lo asigno."
• Equipo en Conflicto - Conversación tipo: Persuación
• "- ¿Les parece si revisan el log de transacciones?"
• Equipo en Normalización - Conversación tipo: Participación
• "-Yo he estado observando que hemos estado siendo más laxos con las pruebas no funcionales, ¿ustedes que piensan?
• Equipo en Desempeño - Conversación tipo: Delegación
• "-¿Qué creen que está sucediendo para que el desempeño de nuestro equipo no esté mejorando los últimos tres sprints?

Respecto a la Caducidad del Scrum Master

Ahora, en esa misma dirección, por lo general una pregunta asociada a este tipo de conversaciones es:

¿El Scrum Master caduca, o deja de ser necesario?

Es como si se afirmara,

como el equipo de fútbol llegó a ser campeón, ya no necesita director técnico

Obviamente, la respuesta es ¡No!, pues entre más maduro el equipo - aunque este requiere menos esfuerzo de facilitación-  las conversaciones cambian y están más ligadas al alto desempeño, y muy similares a las presentada en: Equipo en Desempeño - Conversación tipo: Delegación.

Para cerrar te comparto algo que me ha mostrado la experiencia,

• En la mayoría de los equipos en los que el Scrum Master ha sido removido, desaparece la retrospectiva y por ende la mejora continua

Saludos Ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización - clic aquí -
2. Guía oficial de Scrum- https://scrumguides.org/
3. Comenzando con un equipo en Scrum: Parte 2 - Ciclo de vida de los equipos - clic aquí-
4. Las Preguntas Poderosas como Herramientas para Generar Autoorganización y Autogéstión - clic aquí -.
5. Lecturas recomendadas:
• La caducidad del Scrum Master… y por extrapolación del coach ágil - clic aquí-.
• El objetivo de Scrum Master, NO PUEDE SER, dejar de ser necesario para el equipo - clic aquí -.

Sketch - Explicación de Scrum

Hola a todos

les comparto este boceto que realicé hace poco explicando el marco de Scrum

les comparto este boceto que realicé hace poco explicando el marco de Scrum


También puedes descargarlo en png de alta resolución del siguiente link - clic acá- .

Saludos ágiles

Jorge Abad

De colección: What’s the difference between Scrum and Agile? by Jeff Sutherland

Source: https://www.quora.com/What-s-the-difference-between-Scrum-and-Agile/answer/Jeff-Sutherland-1?srid=hJUg

What’s the difference between Scrum and Agile?

Jeff Sutherland, Inventor and Co-Creator of Scrum

Answered March 30, 2020 · Author has 96 answers and 468.8k answer views

At the Agile Manifeso Meeting in 2001 we wrote a set of 4 values backed up by a dozen principles. This is Agile.

There were 3 experts on Scrum present and 4 founders of eXtreme Programming. These were the only two widely deployed processes. They are related because the founders of both processes were communicating in the internet newsgroups as they were formed and reusing ideas from one another as early as 1994.

The other experts at the meeting had written books and papers on more adaptive and flexible development processes to replace the Rational Unified Process which was dominant at the time in software, but too heavyweight.

So Scrum and XP are the parents of Agile which is not a framework or an operational implementation. The operational implementation of Agile in over 80% of teams today is some variant of Scrum. The fastest teams implement XP practices inside the Scrum.

An extremely important XP practice implemented in the first Scrum teams is continuous integration and deployment at least once a sprint if not more often. The DevOps movement has evolved to promote this practice which was part of the original Scrum and XP teams.

Over 50% of “Agile” teams cannot deliver at the end of a sprint and are late, over budget, with unhappy customers according to Standish Group data on hundreds of thousands of projects. So beware of fake Agile.

---

Traducción

En la reunión del Manifiesto Ágil en 2001, escribimos un conjunto de 4 valores respaldados por una docena de principios. Esto es ágil

Hubo 3 expertos en Scrum presente y 4 fundadores de eXtreme Programming. Estos fueron los únicos dos procesos ampliamente implementados. Están relacionados porque los fundadores de ambos procesos se comunicaban en los grupos de noticias de Internet a medida que se formaban y reutilizaban ideas el uno del otro ya en 1994.

Los otros expertos en la reunión habían escrito libros y documentos sobre procesos de desarrollo más adaptables y flexibles para reemplazar el Proceso Racional Unificado (Rational Unified Process - RUP) que era dominante en ese momento en software, pero demasiado pesado.

Entonces Scrum y XP son los padres de Agile, que no es un marco o una implementación operativa. La implementación operativa de Agile en más del 80% de los equipos de hoy es una variante de Scrum. Los equipos más rápidos implementan prácticas XP dentro del Scrum.

Una práctica de XP extremadamente importante implementada en los primeros equipos Scrum es la integración y el despliegue continuos al menos una vez por sprint, si no con mayor frecuencia. El movimiento DevOps ha evolucionado para promover esta práctica que formaba parte de los equipos originales de Scrum y XP.

Más del 50% de los equipos "ágiles" no pueden entregar al final de un sprint y llegan tarde, por encima del presupuesto, con clientes insatisfechos según los datos del Grupo Standish en cientos de miles de proyectos. Así que ten cuidado con el falso Agile.

Product Owner's Views - Explicación

Hola a todos

Generalmente vemos al Dueño de Producto (Product Owner - PO ) trabajando en dos frentes, en el frente de la definición del producto y en el frente de la construcción del mismo, por medio de este artículo quiero compartir que la visual del PO debe considerar tres frentes(1)(2) para realizar una correcta construcción del producto.

• Vista 1 - Descubrimiento (Discovery):
• En este frente el PO trabaja con el Equipo del Producto (Product Team), que puede estar compuesto por:
• expertos del negocio
• arquitectos de software y arquitectos empresariales
• Expertos en UX / UI
• clientes
• posibles suarios
• expertos en Seguridad y Riesgos
• expertos en Procesos
• gerentes de Producto (Product Managers) 
• otros PO e interesados claves
• Para definir:
• el producto,
• la visión del producto
• la lista ordenada del producto (Product Backlog)
• el producto minimo viable (Minimum Viable Product - MVP) 
• las versiones, 
• los prototípos,
• los indicadores,
• los esquemas de ROI
• las hipótesis, etc.
• Para esto se vale de:
• visitas a clientes y usuarios
• conocer donde va a ser usado el producto (gemba walks)
• investigaciones de mercado
• análisis de la compentencia (benchmarks)
• estrategias de construcción del producto
• dependencia de otros productos o soluciones, etc.
• Vista 2 - Desarrollo (Development): 
• En esta vista el PO proporciona y explica del Product Backlog priorizado y refinado al Equipo de Desarrollo (Development Team) para que el producto sea creado según su conocimiento y capacidades, y basado en los lineamientos del Equipo del Producto.
• Vista 3 - Producción (Production): 
• En esta vista el PO observa si el producto esta siendo usado según las expectativas para las que fue creado y valida la generación de valor del mismo.

De cada uno de estos frentes el Product Owner obtiene valiosa retroalimentación sobre el Producto que debe considerar y balancear de acuerdo a los tiempos y propósitos que tenga identificados con las versiones a liberar; estas retroalimentaciones le sirven para generar una próxima mejor versión y por ende un mejor producto, estas son:

• Retroalimentación 1 (Feedback 1) del ambiente producción y los usuarios, al Equipo de Desarrollo:
• Uso del producto
• funcionalidades más usadas
• funcionalidades menos usadas
• estadisticas basadas en uso
• hipótesis que funcionaron y las que no
• Funcionamiento del producto
• incidentes y bugs a ser priorizados
• problemas de rendimiento y funcionamiento
• estadisticas de desempeño
• problemas de seguridad
• deuda técnica identificada y que debe ser priorizada
• Retroalimentación 2 (Feedback 2) del Equipo de Desarrollo al Equipo del Producto. 
• El equipo de desarrollo comienza a conocer tanto el producto, que se convierte en otro interesado clave (key stakeholder), proporcionando información para la construcción del mismo. Dentro de la retroalimentación brindada pueden estar las siguientes:
• funcionalidades innecesarias
• funcionalidades a adicionar
• estrategias de implementación
• deuda técnica identificada a ser priorizada
• incidentes y bugs a ser priorizados
• retos técnicos
• estimaciones
• nuevas dependencias técnicas
• nuevas dependencias funcionales con otros productos o equipos de trabajo
• Retroalimentación 3 (Feedback 3) del ambiente de producción y los usuarios al Equipo del Producto:
• Uso del producto
• funcionalidades más usadas
• funcionalidades menos usadas
• estadisticas basadas en uso
• hipótesis que funcionaron y las que no
• valor o ROI generado vs. el esperado
• datos que se obtienen de la validación de hipótesis
• Funcionamiento del producto
• incidentes y bugs a ser priorizados
• estadisticas de desempeño
• problemas de seguridad identificados
• problemas de experiencia de usuario identificados
• deuda técnica identificada y que debe ser priorizada
• estadísticas basadas en experiencia de usuario

Bienvenidos sus comentarios

Saludos ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. El análisis acá presentado esta pensado está formulado para productos basados en software, para otro tipo de productos se sugiere realizar análisis similar y reemplazar roles, actividades y fuentes según sea la industria de solución.
2. Este diagrama fue resultado del análisis del dual-track, algunas interesantes referencias a continuación:
• Dual Track Development is not Duel Track - clic aquí
• Dual-Track Agile: Why Messy Leads to Innovation - clic aquí
• Dual-Track Agile - clic aquí
• How to set up Dual-Track Scrum in Jira - clic aquí
3. Gracias a mis amigos Jaime Icaza y Daniel Ramirez por sus valiosos comentarios para mejorar este artículo.