Sobre Scrum Masters & Project Management

Sobre Scrum Masters & Project Management

Continuando con la cuestión de planteada previamente (el sospechoso rol del Scrum Master…) sobre las responsabilidades extra que suelen recaer en aquellas personas que ocupan el rol de Scrum Master en las empresas de desarrollo de Software, hoy quiero referirme puntualmente al Project Management.

Antes que nada hago algunas aclaraciones sobre Management según Agile:

  1. El manifiesto ágil dice explícitamente que el equipo es auto-organizado, lo cual implica que la estrategia de management es distinta a la tradicional (muchas veces taylorista) y que varias tareas de management recaerán en el propio equipo. No está completamente claro cuales de las tareas de management toma el equipo y cuales caen fuera, eso habilita a que cada equipo/organización lo maneje de forma distinta.
  2. Más allá de que el equipo sea auto-organizado es razonable que el equipo tenga que interfacear/reportar/coordinar en algún punto con la organización a la cual pertenece. Una cuestión clave aquí es como de implementa esa interface respetando la auto-organización del equipo.

Más allá de de estas cuestiones conceptuales lo que suelo encontrarme muy frecuentemente en empresas de desarrollo de software es que una misma persona concentra el rol de Scrum Master y también varias tareas de management. En particular hay 2 escenarios muy comunes: 1) Scrum Masters haciendo Project Management y 2) Project Managers haciendo de Scrum Masters.

1) Sobre Project Managers haciendo de Scrum Masters

Esta es gente viene de una experiencia de Project Management y que ahora que “el mundo es Agile” se metió en Scrum y adoptó el rol de Scrum Master. Como ya tiene una experiencia en management no le resulta difícil tomar las tareas de management que le pide la organización. El gran desafío aquí es que esta persona pueda dejar de lado algunas practicas de management porque está trabajando con un equipo auto-organizado. Situaciones típicas en este escenario son:

  • La Daily Standup convertida en un reporte de estado
  • Ver al Scrum Master asignando tareas
  • Tracking y reporte en término de horas
  • Micro-management
  • Percepción del Scrum Master como Jefe del equipo

2) Sobre Scrum Master haciendo Management

En este escenario tenemos gente que se formó/entrenó como Scrum Master y que adicionalmente se encuentra con que debe cubrir tareas de management para las cuales no tiene formación. En este escenario estoy hablando de personas que llegan a ser Scrum Master luego de haberse desempañado como Developer, Tester o algún otro rol pero no Project Managers. En estos casos, si el equipo no tiene la experiencia suficiente para auto-organizarse vemos sufrir al proyecto: no hay métricas, el equipo no tiene una velocidad de delivery predecible ni estable, el cliente ve mucho post-its que en lugar de ayudar a la gestión generan una sensación de desorden y extrema informalidad, la gestión de riesgos es bastante endeble (si es que se hace), y el equipo no tiene la habilidad/capacidad de manejar imprevistos de ningún tipo, etc.

Como ya mencioné no me convence la estrategia de concentrar las tareas de management y Scrum Master en una misma persona, pero si alguna organización piensa hacerlo, espero que al menos tomen la precaución de asegurarse que esa persona que ocupe el doble rol tenga la apropiada formación tanto para las tareas de Scrum Master como también para las tareas de Project Management.

El sospecho rol del Scrum Master en las empresas de desarrollo de Software

El sospecho rol del Scrum Master en las empresas de desarrollo de Software

Una situación que veo recurrentemente en las empresas de desarrollo software para terceros es que conforman sus equipos poniendo una persona en el rol de Scrum Master y asignandole también algunas otras tareas. Esto genera que en términos generales que la persona en el rol de Scrum Master termine concentrando 3 grupos de tareas:

  • a) tareas de facilitación propias del Scrum Master que podemos resumir como ayudar a que el equipo siga la propuesta de proceso de Scrum, removiendo potenciales impedimentos, etc
  • b) tareas típicas de la gestión del proyecto desde la perspectiva de la software factory como ser: seguimiento del presupuesto, planificación del equipo a mediano/largo plazo, seguimiento de la facturación, gestión de riesgos, etc. Aclaro aquí una cuestión importante: la gestión de presupuesto y del plan son responsabilidades del Producto Owner cuando vemos el proyecto desde la perspectiva de la organización que es dueña del producto, pero estas cuestiones también están presentes desde la perspectiva del proyecto de la software factory.
  • c) tareas de gestión internas requeridas por la organización(software factory) respecto de los miembros del equipo como ser evaluaciones de desempeño, coordinación de licencias, etc.

Lo que me resulta sospecho es la concentración de estos tres grupos de tareas en un misma persona porque me parece que puede haber cierto conflicto. Un caso puntual a modo de ejemplo: se supone que el Scrum Master debería generar un contexto de seguridad para que el equipo y sus miembros puedan hablar en confianza sobre sus dificultades, equivocaciones, etc, pero al mismo tiempo esa persona Scrum Master tiene que evaluar el desempeño de los miembros del equipo ¿cuan seguro puede sentirse un miembro de equipo para hablar de sus equivocaciones cuando ese Scrum Master es también la persona que evalúa su desempeño?

Lo que yo recomendaría en estos escenarios es tener dos personas distintas: una con el rol de Scrum Master (que estaría presente en el día a día del proyecto ) y otra con el rol de gestor de proyecto (con una presencia mucho más esporádica).

Manejo de parámetros de deployment en Jenkins

Al implementar un pipeline de deployment suele surgir la necesidad de usar algunos parámetros como ser credenciales para conexión a un server, alguna API Key para interactuar con un cloud provider, etc.

Hay varias formas de manejar esto cuando trabajamos con Jenkins. Hoy quiero compartir una forma que me parece elegante y simple a la vez.

La propuesta es utilizar el soporte de Credenciales que ofrece Jenkins. Para esto vamos a Credentials > Global > Add Credentials.

En la pantalla de agregado de Credenciales elegimos el tipo de credencial que queremos agregar. En este ejemplo voy a elegir una credencial del tipo Secret Text pues quiero guardar un simple API token.

Con esto ya hemos almacenado nuestra credencial en Jenkins. El campo ID es el que utilizaremos a posteriori para referenciar esta credencial.

La forma de usar esta credencial varia dependiendo del tipo de credencial (en este caso es Secret Text) y del “lugar” desde donde querramos accederla por ejemplo si es un FreeStyle job o un Pipeline job.

Para usar esta credencial desde un pipeline job se puede usar el siguiente snippet.

Para usar este credencial desde un FreeStyle job, primero bindeamos la credencial a una variable y luego utilizamos directamente la variable.

Un detalle no menor de esta estrategia es que cuando se ejecuta el job el valor de la credencial es enmascarado.

Sobre mi disertación de Software Delivery en la Maestría del Italiano

Ayer estuve dando una charla sobre Software Delivery en el contexto de la Maestría en Informática en Salud del Hospital Italiano. Esta maestría es relativamente nueva y resulta una oferta interesante para profesionales ya que se dicta en una modalidad semi-presencial: cursada virtual + 2 semanas de cursada presencial por año.

Según me informaron los organizadores en la audiencia de la charla hubo alrededor de 150 personas. Me resultó una experiencia interesante ya que gran parte de la audiencia venía con un background de salud y su acercamiento a la informática era principalmente en roles de gerente, product owners y hasta stakeholders. En línea con esto muchos no estaban en el día a día del desarrollo de software sino más bien en la parte de implementación/operación. Esto me llevo a “moderar” un poco la terminología técnica que suelo utilizar y utilizar algunos ejemplos más relacionados a operaciones y gestión de servicios.

Agradezco a Fernando Campos y Angel Quiroga, docentes de la maestría, que fueron quienes me invitaron a dar esta charla.

Comparto aquí los slides que utilicé.

Historia de un proyecto (no tan) ¿ágil?

En este momento estoy participando en dos proyectos, en uno tengo un rol técnico y en otro un rol más de gestión. A este segundo caso quiero referirme.

El objetivo de este proyecto es reemplazar una aplicación de escritorio con una aplicación web de manera que esta aplicación web ofrezca algunas funcionalidades adicionales. El equipo tiene varios developers y un tester. Yo me sumé al proyecto meses después del primer release (que llevó un 1 año) con el objetivo de intentar mejorar el flujo de trabajo ya que el equipo venia con algunos problemas de estimación, planificación y ejecución. Si bien el propio equipo decía estar trabajando “de forma ágil” en mi opinión no era así, pero a mi parecer esto no era un problema, ya que trabajar de forma ágil no lo veo como un fin en si mismo, sino como un medio para un fin. Desde la perspectiva del cliente el producto entregado estaba muy bien en términos de usabilidad, calidad, etc, pero el proyecto no estaba tan bien ya que el avance era lento y la fecha de fin de proyecto estaba retrasándose recurrentemente. El proyecto tenia una infrastructura de CI con muy pocos tests automatizados, pero con una importante cantidad de casos de pruebas de ejecución manual. El proceso de deployment estaba automatizado.

Lo primero que hice al sumarme al proyecto fue lo mismo de siempre: observar, preguntar y medir. Luego propuse algunos experimentos en la forma de estimar y planificar. A continuación propuse establecer una cadencia en el proceso de desarrollo, hasta ese momento el equipo hacía iteraciones de 10 días hábiles de desarrollo (coding y testing), lo cual hacía que los dias de review y planning cayeran en días variables. Ajustamos esto y establecimos los lunes (cada 2 semanas) como día de review+retro+planning. Todo esto ayudó a establecer un ritmo estable, predecible y facilitó la interacción con los usuarios. Estos cambios también fueron muy bienvenidos por el Product Owner. Antes cada cambio propuesto volvimos a medir para confirmar si se había producido una mejora concreta o no. La semana pasada acordamos establer una cadencia de release haciendo 1 release por mes.

Continuará…

Nueva edición del taller de Prácticas DevOps y Continuous Delivery

Los días 28 y 30 de mayo estaré dictando estos dos taller junto a la gente de 10 Pines. Como siempre hice algunos ajustes en el contenido:

  • Agregué un ejercicio de Kubernetes puro, que complementa el ejercicio de OpenShift que ya tenía
  • Actualicé el setup de los ejercicios de Jenkins para usar Docker como builder
  • Actualicé el material de teoríco incluyendo algunos slides con cuestiones que leí en el workbook de SRE.

Los interesados pueden encontrar más detalles en la página de 10 Pines University:

Sobre el State of Agile Report 2019

Hace un par de dias se publicó este reporte surgido de la encuesta que realiza anualmente la empresa Version One. Los resultados no me soprendieron, al contrario, me resultaron muy familiares respecto de lo que veo en mi día a día.

En el resumen ejecutivo se destacan tres puntos.

1. Scrum (y SAFE) sigue siendo el enfoque agile más popular

No me sorprende y en un punto me parece esperable ya que más allá de las bondades de Scrum, es el enfoque ágil con mayor marketing: Scrum Alliance, Scrum.Org, Certified Scrum zaraza, etc

2. La cultura organizacional es el mayor impedimento para adopción y escalamiento de agile

Me parece esperable considerando que agile es un mindset, una forma de hacer las cosas e incluso un forma de pararse frente a los problemas y desafios

3. DevOps es cada vez más relevante

Tengo la sospecha que esto se debe a que mucha de la gente que trabaja con Scrum, hace en realidad un Flaccid Scrum, o sea, solo aplican la parte de gestión de Agile. Pero en un punto toman conciencia que sin prácticas técnicas varias “promesas de Agile” no son posibles. Pero como ya se gastaron todo el presupuesto de Agile en tomar los curso de “Certified Scrum/Agile XXXX” ahora necesitan otro buzzword para conseguir presupuesto y ahí está DevOps al alcance de la mano.