Atributos de un buen ScrumMaster

Hace poco me encontré con un excelente artículo de Mike Cohn, quien describía los seis atributos que un buen ScrumMaster debe tener y demostrar ante un equipo. Les dejo un extracto para que lo disfruten:

Responsable

Un ScrumMaster no asume la responsabilidad del éxito del proyecto, eso es responsabilidad del equipo. Sin embargo un ScrumMaster asume la responsabilidad de que el equipo adopte el framework y las prácticas de Scrum. El rol de un ScrumMaster es similar al de un conductor de orquesta; ambos deben guiar y liderar a un grupo de individuos talentosos que se unen para crear algo que ninguno de ellos puede crear solo.

Humilde

Un buen ScrumMaster va a enorgullecerse con lo que el equipo pudo lograr, con la ayuda que él le brindo al equipo, no en lo que logro individualmente. Las necesidades del equipo siempre están primeras, y tiene que hacer todo lo necesario para que el equipo alcance su objetivo. Los ScrumMasters humildes reconocen el valor en cada uno de los miembros del equipo y lideran dando este ejemplo.

Colaborativo

Un buen ScrumMaster trabaja para asegurarse que una cultura colaborativa exista dentro del equipo, que cualquier miembro se sienta libre para levantar la mano y que se sientan apoyados al hacerlo. El ScrumMaster debe dar el ejemplo e instaurar la colaboración como la norma en el equipo.

Comprometido

Aunque el rol de ScrumMaster no requiere siempre a alguien comprometido 8 horas por día, se necesita a alguien que se comprometa con el rol. Esta persona se debe sentir tan comprometido con el proyecto y el objetivo del Sprint como el equipo. Los días de un ScrumMaster no deben terminar con impedimentos levantados por el equipo sin tratar, aunque haya temas que tarden días en resolverse.

Influenciador

Para ser exitoso, un ScrumMaster necesita influenciar personas dentro y fuera del equipo. Por ejemplo, algunos miembros del equipo tienen que ser influenciados para que se comprometan más con el proceso o sean más colaborativos. También un ScrumMaster tiene que influenciar al equipo para utilizar nuevas prácticas como TDD. Un ScrumMaster debe saber cómo influenciar al equipo con conocimiento, sin utilizar poder ni dar órdenes.

A veces hay que influenciar gente fuera del proyecto, como por ejemplo convencer a un director de QC que dedique testers full time al proyecto.

Finalmente, un ScrumMaster debe saber cómo utilizar su influencia política dentro de la empresa, para el bien del equipo.

Sabio

Los mejores ScrumMasters tienen el conocimiento técnico, de negocio o para ayudar al equipo a conseguir su objetivo. Un conocimiento detallado de como algo funciona aumenta las chances de que un líder ayudando al equipo encuentre problemas o detecte riesgos que tienen que tratarse.

My Job Went to India

My Job Went to India and All I Got Was This Lousy Book (52 ways to save your Job), escrito por Chad Fawler, nos cuenta como sobrevivir en el nuevo marco mundial del offshoring. El libro esta principalmente dirigido a desarrolladores de Estados Unidos cuyos puestos de trabajo se ven amenazados por desarrolladores de India, con sugerencias para mantenerse empleable frente a esta nueva realidad.

Chad Fawler estuvo viviendo un tiempo en India, armando un centro de desarrollo y nos cuenta su experiencia de trabajo en ese país. Es muy interesante conocer ciertos aspectos de la cultura India. Por ejemplo, en India no está bien visto decir no a algo. Esto puede ser ante un pedido para hacer algo para cierta fecha, y cuando esta se acerca y no lo terminaron, aunque sabían que era imposible, pero no lo dicen por costumbre, siempre piden unos días más para cerrar la tarea. Otro ejemplo es cuando uno explica algo, hay que asegurarse de que lo entendieron, y no conformarse con un sí de ellos. El autor (ni yo) intenta menospreciar a los desarrolladores de India, solo comentar su forma de trabajar. , yo también viví estas situaciones con miembros de equipos en India.

Chad piensa que la carrera de una persona es como el ciclo de vida de un producto, y provee tips y ejemplos prácticos para tomar. Sus consejos son muy buenos, por ejemplo, es común que los desarrolladores no quieran participar de proyectos de mantenimiento de un sistema, pero el autor destaca que luego de la primer línea de código, todo proyecto se transforma en un proyecto de mantenimiento, donde se tiene que agregar funcionalidades o resolver problemas sobre código existente, y recomienda no menospreciar estos proyectos. También recalca que la presencia de uno en la empresa es importante, y que como un producto, uno tiene que hacer marketing de sus habilidades y fortalezas.

Aunque la portada del libro no es de lo mejor y el título puede tener un tono agresivo, los tips del autor son muy interesantes y la redacción es muy entretenida. Por suerte la segunda edición del libro cambio a un título más apropiado: The Passionate Programmer: Creating a Remarkable Career in Software Development