• 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

scrum master

Servant leadership, separando el grano de la paja

Si has leído la guía de Scrum o asistido a uno de nuestros cursos, habrás oído hablar del término servant-leader. Al contrario de lo que muchas personas piensan, el concepto de Servant-Leadership no es nuevo, tiene un fundamento científico fuerte detrás y ha sido adoptado mucho más allá de entornos ágiles por distintas organizaciones a lo largo de muchos lustros.

El Servant-Leadership es un modelo de liderazgo en donde la meta última del líder es servir, a diferencia de los modelos tradicionales en donde la meta del líder es crear una organización o una empresa próspera, lo que puede -o no- alinearse con la meta de servir a la organización.

Alguien que lidere a través del servicio comparte poder, anteponiendo las necesidades de los empleados y ayudando a las personas -incluyendo a los stakeholders- a desarrollar su máximo potencial.

En la formulación original de Robert K. Greenleaf, la pregunta que debe hacer el líder es: ¿Están creciendo aquellos a los que se sirve? ¿Son más saludables, sabias, libres, autónomas, se sienten mejor, más capaces para convertirse en en servidoras también?

Esto, que puede intuitivamente ser asociado a un entendimiento superfluo del liderazgo, ha sido ampliamente estudiado. En un estudio de investigación del año 2002, Sendjaya y Ramos analizan cual es el impacto del Servant Leadership en las organizaciones que deliberadamente han decidido adoptarlo como modelo de liderazgo.

Servant Leadership, un término con más de 50 años

Aunque parezca un término nuevo, el término Servant-Leadership (liderazgo a través del servicio) fue formulado hace casi medio siglo. La idea le surgió a Greenleaf tras leer el libro Viaje al Oriente, de Herman Hesse, que describía la épica aventura de un grupo que decide viajar a Oriente y cuya figura más aparentemente innecesaria, Leo, desaparece, provocando el desarraigo y la separación de un grupo aparentemente cohesionado.

Durante el viaje, Leo se encarga de realizar tareas mundanas y aparentemente veniales: Fregar platos, recoger materiales, pero también animar al resto en cuerpo y alama. Nadie diría que Leo es el pegamento del grupo hasta que éste desaparece.

A Greenleaf le cautivó la idea de que el sirviente fuera realmente el líder y decidió conceptualizar la idea de Servant-Leadership en una persona cuyo éxito se mide por el crecimiento y el éxito de otros, no de sí mismo.

Las características de un Servant leader

En 1998, Larry Spears publicó otro artículo de investigación en el que describía las características más importantes de un líder servicial a raíz de las formulaciones posteriores a la conceptualización inicial de Greenleaf. Éstas 10 características son:

  • Escucha. Aunque los líderes son valorados por su capacidad comunicativa y de decisión, éstas tienen que estar reforzadas por una profunda capacidad de escucha activa hacia los demás. Dado que el compromiso del líder servicial es hacia los demás, aprender a escuchar tanto lo que se dice como lo que no es fundamental para poder accionar decisiones.
  • Empatía. La empatía se puede describir como la habilidad para ponerse en la piel del otro, desprendiéndose de los propios juicios -y prejuicios-. Es importante no confundirlo con la simpatía -sentir lo que siente el otro-. De esa manera, el líder puede utilizar mejor su capacidad de acción.
  • Curación. Ser capaz de sanar y reforzar relaciones es una potente capacidad transformadora y de integración. Una de las grandes fortalezas de un líder servicial es ser potencialmente capaz de sanar las relaciones propias y ajenas.
  • Conciencia. La conciencia de lo que ocurre a su alrededor, y especialmente la auto-conciencia, son dos capacidades que tiene el servant-leader a su disposición para hacer crecer a otros y desarrollar un entorno en el que puedan alcanzar nuevas cotas de potencial.
  • Persuasión. Lo que diferencia la persuasión de la manipulación es la intención. Persuadir es la habilidad de conseguir convencer a alguien para hacer algo en pro de un bien común. La manipulación consiste en convencer a alguien para hacer algo solamente en pro de un beneficio personal.
  • Conceptualización. La capacidad de observar un problema desde una perspectiva de conceptualización significa que uno debe de mirar más allá de los problemas del día a día. Conceptualizar problemas a través del modelado es una habilidad fundamental para un líder servicial.
  • Previsión. Muy relacionada con la conceptualización, la habilidad de preveer los resultados de una acción es difícil de definir pero sencilla de identificar. La previsión es una capacidad que permite al líder servicial aprender del pasado, entender los problemas del presente y generar espacio para la resolución de problemas complejos a través de aquellos a los que sirve.
  • Gobernanza. A diferencia de la dirección, la gobernanza se manifiesta en la capacidad de conseguir consenso en un entorno complejo para alcanzar resultados mayores. Mientras que la dirección implica la toma de decisiones individual, la gobernanza se centra en la creación de marcos donde los miembros del sistema tienen libertad para conseguir metas.
  • Compromiso hacia el crecimiento de las personas. No debería de sorprendernos saber que la mayoría de los líderes consideran a las personas como medios para conseguir sus propios fines y no cómo entes autónomos con sus propias motivaciones cuyo crecimiento ayuda a sumar al sistema.
  • Construcción de comunidad. Por último, los líderes serviciales están muy orientados a la creación de comunidades donde otros pueden tomar el papel de liderazgo en cualquier momento.

Es interesante hacer un inciso para aclarar que en Psicología se distingue entre rasgos y características del carácter. Mientras los primeros pueden no ser modificados y van implícitos en el carácter de la persona, los segundos se adquieren a través del entrenamiento y el aprendizaje.

SLBS-6, midiendo el Servant Leadership


En 2019, Sendjaya junto con su grupo de investigación publicó un cuestionario corto de 6 preguntas, basado en un estudio de dos años antes, para validar la fiabilidad del constructo de Servant-Leadership.

En Psicología, cuando se pretende medir algo a través de un cuestionario, hay que refutar que realmente las preguntas miden aquello que se pretende estudiar. Esto es lo que se determina mediante la validación de las propiedades Psicométricas de las preguntas. En particular se analizan la fiabilidad, la cohesión y la validez del constructo. La escala del estudio consta de seis elementos:

[Mi jefe…]

  • Utiliza su autoridad en servicio de otros, no para su propia ambición
  • Me da el derecho a cuestionar sus acciones o decisiones
  • Me respeta por quien soy, no por cómo le hago sentir
  • Realza mi capacidad para acciones morales
  • Me ayuda a generar un sentido de propósito del trabajo diario
  • Contribuye a mi crecimiento personal y profesional

Servicial no es servil

Es fácil pensar que el objetivo de un líder servicial es servir las necesidades de todas las personas con las que trabaja. Nada más alejado de la realidad.

En la mayoría de las ocasiones y ante un problema, un líder servicial actuará con el objetivo de empoderar a la persona, en lugar de resolverle el problema. Ésta es la diferencia entre servicial -sirve- y servil -lame culos-.

Para terminar, merece la pena hacer una referencia a que el conjunto de prácticas de Management 3.0 puede ayudar a un servant-leader a entender cuales son las motivaciones y obtener retroalimentación para las primeras características que mencionábamos más arriba.


Facilitación Gráfica – Scrum Master

Este miércoles vamos a terminar de ver nuestro Scrum Team y vamos a hacer una pequeña introducción con facilitación gráfica del Scrum Master.

 

¿Quién es el Scrum Master?

Es la persona que se encarga de promover y apoyar Scrum, de ayudar a todo el mundo a entenderlo y a implementarlo. Tiene que ayudar a que estos cambios ayuden a maximizar el valor creado por el equipo. Es un Servant Leader para el Scrum Team y la organización.

En el Scrum Team

¿Cómo se encarga de apoyar a cada uno de los miembros del equipo? De manera global, siempre estará pendiente de que se entiende la visión empírica, de que se entienda Scrum y sus valores y que se practique de manera correcta. También facilitará los diferentes eventos y eliminará los impedimentos que puedan surgir.

 

Scrum Master

¿Os apetece que hablemos de cómo ayuda de manera individual a los miembros del equipo?

El rol de un Jefe de Proyecto en Agile

Cada vez se ven más ofertas -seguirá creciendo en España- que requieren Agile Project Managers o Agile Managers. Eso da lugar a dudas sobre lo que realmente hace un jefe de proyecto ágil. Veámoslo.

Dentro de las diferentes metodologías ágiles, Scrum es la que más específicamente habla de Project Management. En contraposición con metodologías clásicas de desarrollo de Software, el rol del Project Manager está distribuido entre los diferentes roles del equipo Scrum: El Scrum Master, El Product Owner y el equipo de desarrollo.

El Product Owner es responsable de los aspectos de negocio del desarrollo, incluyendo el orden en que el producto se desarrolla y que éste sea desarrollado correctamente. También se encargar de las proyecciones, presupuesto y gestión de los diferentes interesados en el desarrollo del producto (stakeholders).

Ninguna metodología ágil describe el rol de Jefe de Proyecto. Ni siquiera el PMI-ACP, la certificación oficial del Project Management Institute le da una posición destacadaEl Scrum Master se encarga de gestionar el proceso Scrum, funciona como un Coach del equipo, y su autoridad se extiende únicamente al proceso. El Scrum Master no es responsable por el éxito o el fracaso de los proyectos en Scrum. El Scrum Master ayuda al Product Owner a seguir el progreso del proyecto y a reportar a los stakeholders.

El Equipo de Desarrollo se encarga de construir el producto, así como realizar los planes más a corto plazo durante el Sprint Planning, que luego actualizan durante el Daily Scrum, como conseguir los objetivos de proyecto a través de los Sprint Goals, las prácticas necesarias para asegurar la calidad y la mejor manera de construir técnicamente el producto.

Como se puede ver, las responsabilidades clásicas de un Jefe de Proyecto en Scrum están muy bien distribuidas entre los distintos roles en Scrum.

¿Significa esto que no hay necesidad de Jefes de Proyecto en Scrum?

Efectivamente. Los Jefes de Proyectos clásicos, se hagan llamar Agile o no, tienden a ser una interferencia -y habitualmente un impedimento- en proyectos ágiles porque no tienen ninguna responsabilidad de la que hacerse cargo y, en caso de estar, tarde o temprano terminaran colisionando con alguno de los roles existentes en Scrum.

Las empresas que tengan Jefes de Proyecto y quieran adoptar agilidad, especialmente en el caso de Scrum, deben de pensar cual es el nuevo papel que quieren darle a estas personas antes de embarcarse en una transición ágil, dado que, tarde o temprano, en más que probable que se produzcan luchas de poder que no tienen ningún beneficio ni aportan nada a la creación de productos.

 

17 Mitos y falacias de Scrum

Cuando las organizaciones deciden adoptar agilidad, la mayoría opta por Scrum por ser el MÉTODO MAS POPULAR Y UTILIZADO DEL MUNDO. Sin embargo, muchas caen en los mismos mitos y falacias de Scrum. Veamos algunas de ellas y como evitarlas

Un Scrum Master por equipo

Scrum recomienda que en cada equipo exista un Scrum Master y un Product Owner, sin embargo no dice que tenga que ser una persona dedicada totalmente al equipo. Sí advierte de que si no están dedicadas al equipo, eso puede suponer un impacto en la productividad.

Mi opinión es que tener un Scrum Master por equipo es algo fundamental, sobre todo cuando se trata de nuevos Scrum Masters que requieren de tiempo antes de empezar a tener una visión holística del proceso. Hay diferencia de opiniones en este aspecto.

Debe haber un Product Backlog antes de empezar el Sprint

Mito. Aunque es muy positivo que exista un Product Backlog antes de empezar el Sprint, este puede perfectamente realizarse como parte del Sprint Planning e ir refinándose durante el Sprint. De hecho, puede ser una tarea totalmente factible para un primer Sprint.

Lo que Scrum dice es que, independientemente de como se haya iniciado el Sprint, al final de este debe haber un Incremento, es decir, Software listo para entregar al cliente, por pequeño que éste sea.

Los Sprints deben durar dos semanas

Falacia. Los Sprints deben durar lo necesario para poder entregar un Incremento completo y nunca más de cuatro semanas. El motivo es que si duran más, se pierden oportunidades para inspeccionar y adaptar. Si con Sprints de dos semanas no se consigue tener un Incremento “Listo”, entonces hay que revisar la duración del Sprint.

Debe existir una Definición de “Hecho” (Definition of Done)

Falso. La definición de “Hecho” o Definition of “Done” es una práctica recomendada pero no forma parte del núcleo de Scrum. La definición de “Hecho” recoge todas aquellas actividades recurrentes que deben de tenerse en cuenta antes de terminar un Incremento. Esta práctica mejora la transparencia de los Incrementos.

El Daily Scrum es una reunión de sincronización

Falso. El objetivo del Daily Scrum es tener una oportunidad diaria para Inspeccionar y Adaptar. El resultado del Daily Scrum es un Sprint Backlog actualizado con un plan para las próximas 24 horas y lo que va a ocurrir en los próximos días. Muchos equipos acuden al Daily Scrum y se limitan a decir lo que han hecho y lo que harán, o para comunicar impedimentos. Muy pocos realmente tienen un Sprint Backlog actualizado después del Daily Scrum.

Los ítems del Product Backlog deben estar estimados

Verdadero. Scrum dice que los ítems del Product Backlog deben estar lo suficientemente refinados y ser suficientemente pequeños para ser potencialmente entregables al final del Sprint y, además, estar estimados. Scrum no dice si esta estimación debe ser hecha en Puntos de Historia, mediante Slicing u otras técnicas. La estimación es necesaria porque mejora la transparencia y la inspección.

Esto significa que algunos ítems del Product Backlog, los que están más arriba estarán más refinados y mejor estimados y otros, los que estén más abajo, no lo estarán.

Un Product Owner por equipo

Esta es una falacia. Lo que es necesario es un Product Owner por producto. Uno. No más. Es posible tener representantes del Product Owner o Proxy Product Owners en los equipos, y siempre las decisiones serán tomadas por el único Product Owner.

Aquí es donde los Analistas de Negocio pueden jugar un papel fundamental, estando integrados en cada equipo y ayudando al Product Owner en sus tareas.

El Daily Stand-Up tiene que ocurrir con todo el equipo junto de pie

Falso. El Daily Stand-Up no existe en Scrum. Se llama Daily Scrum y puede ocurrir de pie, sentado o a través del teléfono. El Stand-Up es una práctica de eXtreme Programming.

El Scrum Master facilita las retrospectivas

Falso. No sólo no tiene obligación de facilitar las retrospectivas sino que además tiene que participar de ellas. Muchos Scrum Masters comenten el error de que facilitar retrospectivas es su responsabilidad y muchos de ellos no participan como uno más durante la retrospectiva. El Scrum Master es un miembro más del equipo Scrum y, como tal, tiene en la Retrospectiva un espacio perfecto para Inspeccionar y Adaptar el proceso.

El Scrum Master tiene que estar en el Daily Scrum

Falso. El Scrum Master tiene que asegurarse de que existe un Daily Scrum, que este dura como máximo 15 minutos y que se utiliza para mejorar la transparencia del Incremento en proceso. No tiene por qué atender físicamente al evento ni facilitarlo.

Las estimaciones tienen que estar hechas en Puntos de Historia (Story Points)

Falso. Los Story Points son una técnica más para estimar ítems en el Product Backlog. Hay muchas otras técnicas que son igual de efectivas -o más- que los Story Points. Los Story Points no se pueden cambiar de un equipo a otro y son una visión subjetiva de la estimación hecha por un equipo determinado.

Las estimaciones se pueden usar para medir la productividad y predecir cuando un producto estará terminado

Falacia. Uno de los mitos y falacias de Scrum mas típicos. La única manera de medir el progreso en Scrum es software finalizado y listo para entregar al cliente. Eso puede cambiar de Sprint a Sprint dependiendo del entorno. Scrum es genial para desarrollar productos en entornos complejos. Realizar estimaciones en entornos complejos basados en estimaciones subjetivas no sólo es infantil (o wishful thinking) sino que además es peligroso.

Una buena herramienta para reducir la incertidumbre es usar “conos de incertidumbre”. Cuanto más grande sea el Product Backlog, más difícil será tener estimaciones precisas.

El Product Backlog solo puede contener Historias de Usuario

Mito. El Product Backlog debe contener cualquier tipo de tarea necesaria para asegurar que el producto queda como el Product Owner quiere. Esto puede incluir tareas técnicas, documentación o tipos de testing. El uso de una Definición de “Hecho” reduce la complejidad para tareas recurrentes que deben ser completadas cada Sprint

Los requerimientos no funcionales tienen que estar en el Definition of Done

Otro de los mitos y falacias de Scrum. Los requerimientos no funcionales (estabilidad, rendimiento) también pueden estar en el Product Backlog.

El Scrum Master no es un puesto de management.

Falacia. El Scrum Master es un puesto de Management, ya que gestiona el proceso Scrum.

El equipo de desarrollo o el Scrum Master no pueden cancelar un Sprint

Verdadero. El Sprint sólo puede ser cancelado por el Product Owner, cuando este ve que no tiene sentido terminarlo, principalmente debido a que los ítems del Sprint Backlog ya no tienen valor.

Equipo Scrum tiene que tener 7 +/- 2 personas

El ultimo de esta serie de mitos y falacias de Scrum. Scrum recomienda que el tamaño del equipo de desarrollo sea de 3 a 9 personas, pero no prescribe que éste sea el número necesario de personas en un equipo Scrum. El tamaño de un equipo Scrum debe de medirse atendiendo a las necesidades del Transparencia, Inspección y Adaptación

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