• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

responsabilidades

La decisión de subirme al tren de Jerónimo Palacios & Associates

Como algunos sabréis, recientemente me he incorporado a las filas de Jerónimo Palacios & Associates. Me gustaría compartir cómo ha sido esta experiencia y los sentimientos que he ido atravesando. También el porqué de esta decisión y qué ha implicado.

Recuerdo como si fuese ayer mismo el día en que Jero me planteó que colaborásemos juntos. De esto ya hace unos meses. La alegría me invadió completamente. A pesar de ello, no era el mejor momento pues todavía me faltaba trabajo por cerrar en la empresa en la que estaba.

Al tiempo coincidimos de nuevo en un evento de agilismo. De forma totalmente natural retomamos aquella conversación que había quedado en un “ya hablaremos”. Jero continuó contándome el proyecto que estaba preparando, ahora con mayor detalle pues ya lo tenía más aterrizado, y entonces empezó a picarme la curiosidad. Sentí la necesidad de conocer el significado de “unirme al proyecto”.

Freedom & Responsibility

Poco después de aquel día, empecé a degustar el sabor agridulce de tener la libertad de establecer mis propias condiciones, mis propios límites, de escoger qué quería hacer. Tenía delante de mis narices una versión extrema del famoso Freedom & Responsibility, aunque hasta aquel instante no había sido realmente consciente de ello. En este momento la sensación que tenía era de miedo, pues a pesar de que en ocasiones he utilizado este modelo como una referencia que alcanzar o que evangelizar, tengo que reconoceros que cuando fui yo mismo el que podía trabajar bajo sus condiciones, sentí vértigo.

Para los que no conozcáis este modelo, aquí tenéis un enlace a la descripción que hace Netflix de su cultura. Es realmente interesante por lo que si no lo habéis leído, os lo recomiendo. Para los que os dé un poco más de pereza, podríamos destacar que no hay política de horarios, política de vacaciones y a nivel de gastos te piden que gastes como si estuvieses en tu propia empresa. El objetivo es buscar empleados autosuficientes. Para ello te brindan un ambiente de libertad para tomar tus propias decisiones, junto con la responsabilidad que acompaña.

Conversaciones interesantes

Aunque es posible que ya lo hayáis descubierto, quizás todavía os preguntáis cómo me di cuenta que estaba lidiando con esta situación de Freedom & Responsibility. Pues bien, la respuesta es sencilla. Si alguna vez a toda pregunta que hagáis os responden con un “tú verás” o algo por el estilo, es posible que estéis en la misma situación en la que estuve yo. Nadie me ha dicho esto tantas veces como Jerónimo Palacios. Aquí va un ejemplo de conversación:

—¿Qué horario tendré?

—El que tú quieras.

—¿Y vacaciones?

—Las que tú consideres.

—¿Clientes para trabajar?

—Ya veremos. Quizás ya haya, quizás no.

—Entonces, ¿cuál será mi foco?

—Dependerá de ti.

—Vale, ¿y sueldo?

—El que tú consideres.

—¡Arg!

Tenías que haber visto mi cara en aquellas conversaciones, estaba totalmente descolocado. Eso sí, os garantizo que uno de los propósitos que buscaba, al igual que cualquier buen Scrum Master, es que antes de lanzarle cualquier otra pregunta, recapacitaba sobre la posible respuesta que me iba a decir. En ocasiones, incluso se la acompañaba junto a la pregunta para ver si estaba entendiendo el sistema y bueno, eso que le ahorraba porque siempre terminaban de la misma forma.

Un mar de dudas

Volviendo al camino que os estoy contando, aquí estoy, trabajando en Jerónimo Palacios & Associates desde hace pocas semanas. Y ahora bien, ¿qué ha supuesto para mí tener que enfrentarme a estas decisiones, a este modelo? ¿Qué me ha proporcionado y por qué finalmente decidí dar el paso? Tengo que reconocer que a nivel profesional nunca me ha costado tanto tener que tomar una decisión, más cuando contaba con la suerte de tener sobre la mesa otras ofertas que sí establecían unos límites muy claros al igual que unas condiciones muy interesantes.

Bajo mi punto de vista, lidiar con una situación así me ha hecho avanzar un peldaño más en la escalera de la madurez, pues no sólo me ha hecho reflexionar nuevamente sobre qué quiero hacer y hacia dónde quiero ir, sino que me ha llevado a hacerme preguntas del estilo a, ¿cuánto vale mi trabajo? ¿Qué retorno de inversión soy capaz de producir? ¿Cuánto estoy dispuesto a dedicar a mi trabajo? Y es que en este modelo eres tú el que establece la mayoría de las reglas pero todas ellas bajo una condición: máximo cada tres meses tenemos que sentarnos, inspeccionar ingresos y gastos, adaptando la estrategia de ser necesario.

Y más dudas

Puede parecer que ya han acabado las dudas pero no es así. Vienen otras preguntas nueva a la mente: ¿cuánto negocio hay? ¿En qué ubicación? ¿Qué tarifa es la más adecuada? ¿Seré capaz de producir tanto como para que la empresa pueda asumir lo que me gustaría cobrar? Pues un dato que es importante es que no sólo debes producir lo que recibes neto, sino que a eso hay que añadirle gastos de empresa, Seguridad Social, fondo de emergencia, etc. En resumen, a lo que te gustaría cobrar puedes sumarle aproximadamente un 40% más y eso es lo que le cuesta a la empresa. Sí, un 40% más, ¿asombrado?

Lo bueno de este sistema es que todas las decisiones dependerán en primer lugar de ti mismo. Digo en primer lugar porque lógicamente siempre habrá alguien ahí para ver si lo que está ocurriendo tiene sentido o no, pudiendo establecer un punto de inspección y adaptación si es necesario. Al depender de cada uno, es donde podemos empezar a pensar de forma totalmente subjetiva, lo que queremos y lo que necesitamos, pues habrá quién quiera y necesite más, y habrá quien quiera y necesite menos. La empresa lo único que espera es que generes beneficios, obvio ¿no?. En cualquier caso, si no está siendo así, siempre están esos puntos de inspección y adaptación donde poder analizar qué está ocurriendo, qué estrategia se está siguiendo y si hay que adaptar en consecuencia.

Decisión

Sinceramente, a día de hoy estoy encantado de haber tomado la decisión de unirme a esta aventura. Me está permitiendo hacer reflexiones que nunca hice, aprender a un ritmo con el que jamás hubiese imaginado, aportar valor directo a las personas con las que trabajo, a las que estoy ayudando en su aprendizaje o con las que colaboro. Sabéis qué es lo mejor de todo, que lo estoy haciendo siendo extremadamente feliz.

Me gustaría terminar este artículo diciendo que cuando digo “decidí” quiero decir “decidimos”. Sin el apoyo de mi familia y en especial de mi mujer, seguro que finalmente no me hubiese atrevido a dar el paso. Gracias por todo.

Scrum Masters: El bueno, el feo y el malo

Hay una secuencia lógica que aquellos alumnos que han asistido al curso de Professional Scrum Master experimentan: Darse cuenta que Scrum no es en muchas ocasiones lo que ellos pensaban. Preguntarse qué hace el Scrum Master todo el día. Y una tercera que revelaré más adelante.

La mayoría de las organizaciones entienden al Scrum Master en un rango que va del Jefe de Proyecto latigador clásico al Psicólogo de equipo, pasando por el entretenedor y facilitador oficial. Sin embargo, esas no son sus funciones.

Lo que dice la guía de Scrum es: El Scrum Master se encarga de gestionar y mantener Scrum y de eliminar impedimentos. La primera parte está clara. Asegurarse de que Scrum funcione, bien explicando cual es el valor de cada uno de los elementos de Scrum (+10 Scrum Master) bien organizando y forzando a la organización a seguirlos (+0 Scrum Master).

La segunda está menos clara. La mayoría de las interpretaciones van por el camino de facilitarle la vida al equipo, facilitar que el equipo pueda entregar y facilitar que el producto salga adelante. Esto, que no deja de ser correcto, da lugar a ciertos problemas.

Muchos Scrum Masters con poca experiencia de verdad en Scrum optan por centrarse en el equipo. Facilitar que el equipo haga reuniones y que tenga las herramientas que necesitan a su disposición, en ocasiones encargándose personalmente del mismo.

Sin embargo, aquellos que tienen experiencia, dejarán al equipo de desarrollo autoorganizarse y se centraran en eliminar impedimentos a la agilidad organizacional: desde explicar y hacer entender el valor de Scrum hasta la interacción con la organización de desarrollo para incorporar mejores herramientas, pasando por identificar y explorar que mejoras internas se pueden hacer para que el equipo se autogestione mejor.

Si no lo has leído bien, lo repito. Los Scrum Masters más malos son aquellos que se centran en facilitarle la vida al equipo, impidiendo que sean ellos los que se auto gestionan, mientras que no promueven el cambio organizacional para que la organización mejore.

Un ejemplo: En uno de mis clientes, mientras que uno de los Scrum Masters se afanaba en ayudar al equipo a finalizar el testing para entregar al final del Sprint, otro explicaba a la organización cual es el valor de invertir en testing automatizado.

Una vez que el mensaje había calado, los equipos de desarrollo se hicieron cargo de implementar todo el proceso. El Scrum Master del primer equipo se quejaba de que ahora no tenía mucho que hacer. ¡Claro! Nunca había hecho realmente su trabajo.

Influenciar sin autoridad

En otro cliente, los Scrum Masters habían formado una especie de sindicato donde se reunían para llorar sus penas y exigir mejoras. Se llamaba el Scrum of Scrums. Al final, consiguieron que la organización los nombrara a todos Development Leads. A los pocos meses dejaron de hacer Scrum para hacer un híbrido que se inventaron. Hoy lo anuncian en twitter como la nueva revolución ágil.

El dilema del Scrum Master es precisamente ese: Cómo influenciar a la organización sin autoridad para hacerlo. Los Scrum Masters no deben de tener autoridad en la jerarquía funcional de la organización. Hacerlo supone dar un poder que no necesitan en primer lugar.

Mi día a día como Scrum Master

Cuando ejerzo de Scrum Master, generalmente no voy a los Daily Scrums ni facilitó Retrospectivas. Estas cosas bien puede hacerlas un equipo de desarrollo que se auto organiza. Cada vez que hago algo por el equipo que pueden hacer ellos, les estoy quitando una oportunidad de aprendizaje.

Así que me centro en lo que impide que el equipo de desarrollo y el producto avance. E intento evangelizar, apoyar, mentorizar y explicar cómo las cosas se pueden hacer ágilmente. Todo el tiempo libre que -deliberadamente- tiene el rol está para eso, no para arreglar teclados a los miembros del equipo de desarrollo.

Aquí llegamos a la tercera revelación de los alumnos del PSM: Eso es tremendamente difícil Jero. Ya. Lo se. Nadie dijo que fuera fácil. Fácil es tener un rol como el de Scrum Master y pintar dibujos a lo largo de toda la empresa mientras el conocimiento sobre Scrum es nulo, el pipeline de Delivery es desconocido y la empresa sigue funcionando por proyectos.

Además de fácil, es un poco irresponsable.

Qué hacer cuando el Product Owner está ausente

Esta es una situación común en muchas organizaciones que empiezan con Scrum en su búsqueda de la solución a todos los problemas.

El Product Owner no existe o está ausente todo el tiempo, lo que hace que recaiga todo el trabajo encima del equipo de desarrollo. Veamos que hacer.

Si no hay Product Owner o Scrum Master

Uno de los alumnos de mis clases era el CTO de una empresa mediana de desarrollo de herramientas para Recursos Humanos. Después del primer día de clase, en las preguntas finales del día, levantó la mano y dijo: Pero… si no hay Scrum Master o Product Owner, Scrum se puede adaptar, ¿No?

La respuesta es NO. Scrum requiere muy pocas cosas. Un Product Owner, un Scrum Master, un Equipo de Desarrollo.

Si no somos capaces de poner dos de esas tres, no vamos a obtener muchos beneficios.

Esta situación es típica de empresas muy rígidas que están afrontando problemas verdaderamente graves pero que buscan una solución fácil.

Todo les vale mientras no tengan que cambiar. Lo siento. Malas noticias. Scrum requiere unos cambios mínimos para avanzar.

La solución en este caso es, simplemente, no hacer Scrum. No llamar a lo que hacemos Scrum, porque el día que decidamos darle un oportunidad, los miembros de la organización ya tendrán una visión negativa del mismo.

Es mejor implementar algunas prácticas de XP, como el Daily Standup, Release and Iteration Planning o una base de código compartido que intentar hacer Scrum.

XP es una introducción perfecta a muchas prácticas que se utilizaran más adelante en Scrum.

Si el Product Owner está ausente todo el tiempo

Esta segunda situación es bastante común, y se da también en empresas consultoras que nominan como Product Owner al cliente sin pensar siquiera si entiende lo que esto supone.

El nivel de colaboración entre el Product Owner y el equipo de desarrollo es muy necesario, pero la mayoría de los Product Owners lo que entienden es que es un representante del negocio.

Nada más alejado de la realidad. El Product Owner es el negocio y no estando disponible para el equipo de desarrollo está poniendo en riesgo la inversión que supone dedicar un Sprint a hacer Software sin tener ningún feedback.

Al final, es el Product Owner el que tiene que dar la cara por todas las decisiones que se han tomado en torno a qué invertir el tiempo durante el Sprint.

Un Sprint del equipo Scrum cuesta de 25.000€ a 75.000€ por Iteración y es el Product Owner el responsable de manejar ese presupuesto. Una buena pregunta para el Product Owner ausente es: ¿En que hemos invertido los últimos 25/50/100.000€?

Es habitual que aquellos Product Owners que están demasiado ocupados para dar la cara respondan que ellos no manejan el dinero. Incluso se sientan ofendidos.

En la mayoría de las ocasiones, esta situación viene dada por no entender cuales son sus responsabilidades. Alguien les ha explicado que tienen que representar al cliente y las ha recomendado ver Scrum en 8 minutos o Scrum explicado a mi abuela, pero nunca les han explicado por qué existe el perfil.

Mi recomendación en este caso es invertir tiempo en explicar al Product Owner cual es el sentido del rol en Scrum. Empezar por preguntas como ¿Donde has invertido los último X€ de la empresa? llamará su atención lo suficiente como para propiciar una conversación

Cuando el Scrum Master o el equipo toman la responsabilidad del Product Owner

En algunos equipos ocurre algo distinto. El Product Owner delega en el Scrum Master o el equipo de desarrollo la toma de decisiones sobre lo que hacer. Esta opción es válida en Scrum, siempre y cuando tengamos claro que el último responsable de lo que haga el equipo sigue siendo el Product Owner.

Se puede delegar el hacer el trabajo pero no la responsabilidad sobre el trabajo. Un ejemplo típico sería el del Product Owner que ha estado ausente y llega al Sprint Review a quejarse del trabajo. Lo primero que hay que apuntar es que él o ella son responsables de lo que ha ocurrido y que han preferido no ejercer su rol y dejarlo a otros.

Cuando el Scrum Master toma la iniciativa de cubrir al Product Owner, no sólo le está haciendo un flaco favor al resto, sino que además está haciendo mal su trabajo como SM. El objetivo final del rol del Scrum Master es que Scrum funcione. Tomando la iniciativa de cubrir al PO, lo único que está haciendo es tapar las distinciones y problemas del marco de trabajo.

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad