martes, marzo 28, 2017

Las habilidades blandas -Soft Skills- de un Scrum Master


Hola a todos:

Quisiera compartir en este post un poco más del entendimiento que he logrado del rol de Scrum Master, este rol tan extraño que hace poco hemos comenzado a emplear en proyectos de desarrollo de software.

Según la Guía Oficial de Scrum (1), el Scrum Master (SM). lo define como:
  • es el responsable de asegurar que Scrum se entienda y se adopte
  • es un líder que está al servicio del Equipo Scrum (Ojo: Recordemos que el Equipo Scrum esta compuesto por el Equipo Desarrollador (2), Scrum Master y Product Owner)
  • ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser útiles y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones para maximizar el valor creado por el Equipo Scrum.
  • Facilitar los eventos de Scrum según se requiera o necesite.
  • Sirviendo al Product Owner en:
    • 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; 
  • Sirviendo al Equipo Desarrollador (2) en:
    • Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional;
    • Ayudar al Equipo de Desarrollo a crear productos de alto valor;
    • Eliminar impedimentos para el progreso del Equipo de Desarrollo;
    • Guiar al Equipo de Desarrollo en entornos organizacionales en los que Scrum aún no haya sido adoptado y entendido por completo.
  • Sirviendo a la Organización en:
    • Liderar y guiar a la organización en la adopción de Scrum;
    • Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico de producto;
    • Motivar cambios que incrementen la productividad del Equipo Scrum; y,
    • Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización.
Podríamos parafrasear o abstraer todo esto en
  • El Experto y Maestro de Scrum
  • Quien enseña al Equipo Scrum a hacer Scrum
  • Facilitador de los eventos de Scrum
  • Líder Servicial (al servicio del equipo Scrum)
  • Agente de cambio
  • Coach del Equipo Desarrollador y del Product Owner
  • Remueve impedimentos 
  • Protege y guía al Equipo Scrum y a la Organización la forma como estos interactuan más efectivamente.
Podríamos decir entonces:
"Wow que rol tan importante dentro del equipo, alguien que lidera y sirve al equipo a la vez", 

Pero el lío viene cuando tenemos que salir a elegir dentro de nuestra organización o contratar Scrum Masters en el mercado, Definitivamente no es fácil, pues a la luz de las definiciones mostradas anteriormente la mayoría son blandas y se podrían resumir en:

  • Liderazgo de equipos*
  • Liderazgo Servicial (propone y cuestiona, pero no impone) (4)
  • Trabajo en equipo
  • Don de Maestro
  • Proactividad
  • Comunicación Asertiva
  • Constante autoformación
  • Orientación al logro* (o sea, hace que las cosas pasen)
*La orientación al logro y el liderazgo son cruciales para que un Scrum Master sea exitoso, pues no tiene presentación que este sea una víctima:
  • del Product Owner, 
  • del Equipo Desarrollador 
  • o de la organización. 
Un buen Scrum Master logra tener éxito haciendo Scrum en el escenario complejo en el cual se desarrolla la construcción del proyecto, valiéndose de las herramientas que le proporciona Scrum y la agilidad, e insisto no es una víctima del entorno, es un protagonista que energiza al equipo y presenta radiadores de información que ayuda a todos a tomar acciones oportunamente.

"Un buen Scrum Master logra tener éxito haciendo Scrum en el escenario complejo en el cual se desarrolla la construcción del proyecto."

Según el marco solo requiere una competencia cognitiva:
  • Maestría en el Framework de Scrum (es importante aclarar que dos días de entrenamiento en scrum no convierten a nadie en MAESTRO), lo que se podría resumir en;
    • Saber como facilitar un planning (clic aquí)
    • Saber como facilitar un daily (clic aquí)
    • Saber como guiar al equipo durante el sprint de manera que se logre la autoorganización
    • Saber como facilitar un review (clic aquí)
    • Saber como facilitar una retrospectiva (clic aquí)  
    • Saber como facilitar un refinamiento (clic aquí)
    • Saber como hacer el rol de Product Owner (pues el SM es su coach)
    • Saber como se hace planeación de un producto
    • Saber como se hace la estimación de un product backlog, un sprint backlog y el seguimiento del mismo
    • Saber sobre agilidad
    • Saber sobre prácticas técnicas ágiles (para el mundo del software), o las herramientas que hacen a su equipo más eficiente (pensando en la aplicación de scrum en un escenario agnóstico - o fuera del software - ) (recomiendo este post : Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo - Clic aquí- )

Y por último, es requerido que el Scrum Master tenga conocimientos básicos (no es necesario que sean avanzados - pues para eso está el equipo -) del escenario técnico en el cual se desenvuelve el proyecto o la construcción del producto, pues sino el primer impedimento sería el Scrum Master al no tener herramientas suficientes para saber cómo o quién puede ayudar a su equipo.


Bueno, hasta acá este compartir.

Próximo post relacionado con este ¿cómo encontrar, contratar o formar un scrum master? - clic aquí -.

Bienvenido el feedback

Saludos ágiles

Jorge Abad.





Notas, Aclaraciones, Comentarios y Referencias
  1. Guía de Scrum - clic aquí para descargarla. De igual forma les recomiendo leerla, encontrarán elementos que de seguro estaban ocultos a su primer entendimiento (como me pasó a mí).
  2. El nombre del Equipo de Desarrollo crea por lo general confusión en la industria del software, se debería llamar Equipo Solucionador
  3. Dos buenos links que me sirvieron de gran utilidad para escribir este post  https://www.scrumalliance.org/community/articles/2013/july/soft-skills-for-scrummasters  -- http://www.yodiz.com/blog/10-essential-skills-every-scrum-master-must-have-infographics/
  4. Las Preguntas Poderosas como Herramientas para Generar Autoorganización y Autogéstión - Clic aquí -

miércoles, marzo 22, 2017

[Scrum] El Product Owner "NO" Necesariamente Escribe las Historias de Usuario o Ítems de Backlog

Hola a todos

Como lo había compartido en el post anterior (clic aquí) el Product Owner:

  • Es alguien con empoderamiento y capacidad de decisión sobre el producto
  • Es el responsable del  ROI -return on investment-
  • Es voz del cliente ante el equipo
  • Define, refina y prioriza el Product Backlog
  • Esta disponible para el equipo
  • Hace seguimiento del avance y la construcción del producto
  • Decide cuando cancelar el sprint 
  • Decide cuando salir a producción.

Pero lo que quiero resaltar en este post es lo que dice la guía(1) dice expresamente acerca del Product Backlog y la Lista de Elementos (o ítems) del Producto y como debería trabajar con ella el Product Owner


"El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto (Product Backlog). La gestión de la Lista del Producto incluye: 

  • Expresar claramente los elementos de la Lista del Producto;
  • Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible;
  • Optimizar el valor del trabajo que el Equipo de Desarrollo realiza;
  • Asegurar que la Lista del Producto es visible, transparente y clara para todos y que muestra aquello en lo que el equipo trabajará a continuación; y,
  • Asegurar que el Equipo de Desarrollo(2) entiende los elementos de la Lista del Producto al nivel necesario. 
El Dueño de Producto podría hacer el trabajo anterior o delegarlo en el Equipo de Desarrollo*. Sin embargo, en ambos casos el Dueño de Producto sigue siendo el responsable de dicho trabajo."

Cabe aclarar que he estado en proyectos donde las historias de usuario o ítems de backlog son escritas por otra persona diferente al Product Owner que no hace parte del Equipo Scrum(2), pero esto no exime que el Produt Owner siga al frente de este trabajo y de sus responsabilidades frente al Equipo y al Producto.



Por lo tanto, el Product Owner (de un producto de software), respecto a
  • los requerimientos en prosa,
  • historias de usuario,
  • casos de uso, 
  • o cualquier forma de expresar la Elementos del Producto o ítems de backlog
 podría de acuerdo a su contexto:
  • Elaborar la Lista de Elementos del Producto (Product Backlog) - esta es la práctica más común  -,
  • Delegarla o apoyarse en el equipo de desarrollo para su construcción, o
  • Delegarla en otros por fuera del equipo de desarrollo - esta es fruto de mi experiencia y de varios coaches en la industria, y nos ha sido bastante útil en contextos donde el Product Owner no tiene tiempo para explicitar reglas de negocio compleas -.
Cada Equipo Scrum debe experimentar y entender cual es la configuración que más le conviene.

Basados en la sorpresa anterior quisiera hacerte una pregunta:
¿Cuándo fue la última vez que leíste la guía de Scrum? 

Es bueno leerla cada cierto tiempo, pues en la medida que ganas conocimiento y destreza con Scrum la lees y la comprendes mejor.

Hasta acá esta pequeña nota curiosa.

Les recomiendo este otro post  Un vistazo a la guía de Scrum - Clic Aquí relacionado con la guía y sus apartes "ocultos a nuestro rapido mirar" de mi estimado amigo Lucho Salazar - @LuchoSalazarC traductor de la versión actual al español.

Saludos Ágiles

Jorge Abad



Notas, Aclaraciones, Comentarios y Referencias
  1. Guía de Scrum - clic aquí para descargarla. De igual forma les recomiendo leerla encontrarán elementos que de seguro estaban ocultos a su primer entendimiento (como me pasó a mí).
  2. Recordemos que el Equipo Scrum esta constituido por: El Product Owner, El Equipo de Desarrollo y el Scrum Master.

domingo, marzo 12, 2017

[Scrum] El Valioso "NO" del Product Owner

Hola a todos

Según la Guía de Scrum(1), el Dueño de Producto o Product Owner (PO). lo define como:
  • El responsable de maximizar el valor del producto y el trabajo del Equipo de Desarrollo (2)
  • Es la única persona responsable de gestionar la Lista del Producto (Product Backlog)
  • Expresa claramente los elementos de la Lista del Producto;
  • Ordena los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible;
  • Optimiza el valor del trabajo que el Equipo de Desarrollo realiza;
  • Asegura que la Lista del Producto es visible, transparente y clara para todos y que muestra aquello en lo que el equipo trabajará a continuación;
  • Asegura que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al nivel necesario.
  • Es una única persona, no un comité. El Dueño de Producto podría representar los deseos de un comité en la Lista del Producto, pero aquellos que quieran cambiarla prioridad de un elemento de la Lista deben hacerlo a través del Dueño de Producto.
  • Para que  pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones
  • Durante el Sprint el alcance puede clarificarse y renegociarse entre el Dueño de Producto y el Equipo de Desarrollo a medida que se va aprendiendo más.
  • Solo el Dueño de Producto tiene la autoridad para cancelar el Sprint
  • El Dueño de Producto hace seguimiento de este trabajo restante total al menos en cada revisión de Sprint.
  • Decide si libera o no el incremento
Lo anterior podríamos parafrasearlo un poco como
  • Es alguien con empoderamiento y capacidad de decisión sobre el producto
  • Es el responsable del  ROI -return on investment-
  • Es voz del cliente ante el equipo
  • Define, refina y prioriza el Product Backlog
  • Esta disponible para el equipo
  • Hace seguimiento del avance y la construcción del producto
  • Decide cuando cancelar el sprint 
  • Decide cuando salir a producción.
Pero este post se enfoca en que le corresponde Product Owner respecto al producto y al alcance decir
  • qué se hace 
  • y qué se posterga para próximas versiones (un NO PARCIAL, o sea hoy te digo que NO, mañana tal vez lo hagamos)
  • y qué definitivamente NO SE HACE



Esto se alinea perfectamente con el décimo principio ágil (3) en donde se refleja el pensamiento Lean:

la simplicidad o el arte de maximizar la cantidad de trabajo no realizado es esencial

Decifrando este juego de palabras podemos parafrasearlo diciendo para el mundo del software

Nos esforzaremos al máximo en NO crear ni software, ni alcance, ni trabajo de desperdicio o que no sea necesario (o hacer algo que terminará siendo inútil)

Por lo tanto, es clave que el Product Owner aprenda de a DECIR NO, y al negociar con sus interesados para ciertas funcionalidades les dirá:
    • eso NO se puede hacer aún, 
    • es que necesitamos generar valor con lo mínimo posible
    • eso va para otra versión o release
    • eso aun NO tiene prioridad
    • eso NO agrega valor
    • eso definitivamente NO se hará
Es decir la misión del PO es mantener el Backlog de cada release lo mas pequeño posible de forma que se genere valor con la menor cantidad de alcance requerido y de esa manera se alcance prontamente el máximo ROI.


Cerrando

Un buen PO sabe:
  • Que cada sprint tiene software funcionando y potencialmente liberable (punto a favor del PO y de la organización)
  • Pero que si se permite decir que SÍ todas las funcionalidades que se le ocurran tanto a el como al negocio, NUNCA va a salir a producción, pues a mayor alcance más cantidad de sprints se van a requerir para salir a producción, y a mayor tiempo menor ROI (un peligroso circulo vicioso)
  • Que si se demora mucho en salir a producción el impacto en el ROI y en el negocio puede ser nefasto dado lo disruptivo y cambiante del entorno actual.

Recuerdo mucho una frase que le escuche a Ángel Medinilla.
NUESTRO TRABAJO NO ES HACER SOFTWARE, ES HACER LA MENOR CANTIDAD DE SOFTWARE POSIBLE QUE MAXIMICE EL VALOR DE NEGOCIO DE NUESTROS CLIENTES.

Por lo tanto cuando vayas a escoger a un PO, cerciórate de que el o ella tienen claro los siguientes aspectos respecto al alcance:
  1. Que conoce que problema de negocio está resolviendo
  2. Que tiene claro cual es la solución que debe entregar al negocio para resolver ese problema
  3. Que dice NO, pues esta interesad@ en salir a producción lo antes posible
  4. Que comprende que el NO es de las mejores formas de controlar el ROI
Bienvenido el Feeback

Saludos ágiles

Jorge Abad



Notas, Aclaraciones, Comentarios y Referencias
  1. Guía de Scrum - clic aquí para descargarla. De igual forma les recomiendo leerla encontrarán elementos que de seguro estaban ocultos a su primer entendimiento (como me pasó a mí).
  2. El nombre del Equipo de Desarrollo crea por lo general confusión en la industria del software, se debería llamar Equipo Solucionador
  3. Principios ágiles - http://agilemanifesto.org/iso/es/principles.html
  4. Este post está altamente relacionado con: La Ilusión del Control o ¿Cómo Hago para Controlar un Proyecto Ágil?