Buscar en Gazafatonario IT

lunes, octubre 28, 2013

De Jedi Master a Scrum Master

"Irás al sistema Dagobah. Allí aprenderás de Yoda, el Maestro Jedi que me enseñó."
Obi-Wan Kenobi a Luke Skywalker [Star Wars Episode V: The Empire Strikes Back]
De Jedi Master a Scrum Master
Jedi Master era el rango más alto que un Jedi podía obtener. Era un requisito para poder formar parte del Alto Consejo Jedi, que era el principal medio de comunicación entre los Jedi y el gobierno de la Antigua República. Este era un título reservado para individuos que habían demostrado devoción y habilidad excepcional en la Fuerza. El rango generalmente estaba reservado para Caballeros que habían tenido éxito en convertir a varios padawan en Caballeros. Cuando un Caballero sentía que su padawan estaba listo(a), el Consejo normalmente elevaba el rango del padawan a Caballero y el Caballero a Maestro(a) bajo la condición de que el pupilo pasara una serie de pruebas. Este título también podía ser otorgado a un Caballero por acciones extraordinarias, pero este era un caso muy escaso. [1]

El Scrum Master y la Comunicación

Pero ¿qué tiene que hacer un Jedi Master en este lado de la galaxia para convertirse, para ser un buen Scrum Master? De entre las muchas respuestas que surgen, estas llaman mi atención: obtención de información, lograr que las personas se comuniquen y descubrir y discutir (algunas veces resolver) impedimentos. Como siempre, no está de más el excelso conocimiento que debe tener de Scrum como tal, para que pueda velar porque se cumplan sus reglas como lo dice la Guía. Pero es el asunto de la comunicación el que me va a ocupar a continuación.

Ser un facilitador de la comunicación es uno de los talantes cardinales que distinguen a un excelente Scrum Master. Como conductor de la información es donde un Scrum Master agrega el mayor valor al equipo y a la organización. De hecho, el rol sería menos crítico si el equipo y los interesados fueran capaces de comunicarse mejor entre ellos, pero esto generalmente no ocurre. Es bien sabido la comunicación es un problema inherente al ser humano y que está más arraigado entre quienes trasegamos diariamente por los vericuetos de la Ingeniería de Software. Un estudio de la Universidad de Case Western Reserve en Estados Unidos concluyó que “cuando el cerebro humano se aboca por completo a una tarea que requiere sus habilidades analíticas, sus habilidades sociales simplemente se van de vacaciones.” [2]

Cuando el Scrum Master está lejos se presentan vacíos en la comunicación entre los miembros del equipo y entre estos y el resto de la organización. Una de las situaciones más comunes se presenta cuando en una reunión diaria un miembro del equipo de desarrollo justifica su falta de productividad o de trabajo argumentando que otra persona del equipo o el Dueño de Producto no le ha entregado cierta información que requiere. Es en esos momentos en los que se evidencia la falta de un Scrum Master que ayude a salvar esos hoyos negros comunicativos y le explique al desarrollador que esa otra persona no muerde, que bien puede reunirse con él (ella) en vez de estar esperando la respuesta a un correo electrónico, que siempre recuerde el valor del manifiesto ágil: “Personas e interacciones sobre procesos y herramientas”.

El Scrum Master, el Equipo y la Organización

Adicionalmente, un Scrum Master debe entender la cultura de la organización para generar buenos momentos de implementación del proceso y para que la nueva cultura ágil sea consistente con la visión actual de la organización. El Scrum Master debe además guiar y apoyar a cada individuo en el uso de Scrum y de las prácticas ágiles relacionadas.

Este es un rol que evoluciona junto con sus responsabilidades y que evoluciona en círculos, ya que siempre habrá un equipo nuevo, un miembro nuevo, un proyecto nuevo; de tal suerte que la paciencia es una virtud que todo Scrum Master debería tener. También la flexibilidad, para ser capaz de colaborar con diferentes personalidades y para enfrentar los diversos obstáculos que encontrará en el camino, desde la persona ultra-radical a la que nada le sirve, pasando por el individuo pasivo hasta el proactivo que quiere hacer de todo.

Un buen Scrum Master es el pegamento del proyecto así como su capa protectora externa. En el interior, el Scrum Master sirve como apoyo y ayuda para que todo, y todos, esté(n) en continuo movimiento. En el exterior, debe ser capaz de maniobrar cualquier posible interferencia que pueda poner en problemas al equipo. Su táctica debe ser averiguar qué hacer en el momento adecuado, alineando Scrum con el sentido común, que algunas veces no es tan común.

Ahora bien, no hay un modelo de Scrum Master universal, un comodín, ya que cada proyecto y cada equipo es una galaxia dentro del universo de la Ingeniería de Software, y cada uno de aquellos se despliega en un contexto diferente en cada organización. Aun durante el mismo proyecto, en distintas etapas, es muy probable que el Scrum Master requiera mostrar habilidades específicas.

¿Quieres ser Scrum Master con habilidades extraordinarias?

Nigel Steane, en su blog Agile Experience, menciona estos 10 atributos que todo buen Scrum Master debe tener [3], muy a la usanza de los Jedi Master:

10. Ilumina el camino hacia un futuro más brillante para tu equipo - remover impedimentos
9. Haz el viaje con tu equipo y comparte el camino - promover el Burndown diario
8. Reconoce que eres un líder al servicio de los demás - facilitar el manejo del backlog de producto
7. Se consciente del (software) legado que estás creando - implementar prácticas ágiles de ingeniería
6. Involucra al equipo en la mejora continua - facilitar Retrospectivas del Sprint, actúa sobre los hallazgos
5. Asegúrate que el equipo tenga la siguiente Historia cuando la requiera, y que no sea seleccionada al azar – promueve y desarrolla un equipo multifuncional
4. Sigue el marco de trabajo de Scrum - Asegúrate de contar con los roles correctos para garantizar el éxito
3. Fomenta la comunicación - asegúrate de que la reunión diaria se lleve a cabo
2. Conviértete en un embajador Ágil - transmite los beneficios de Scrum
1. Da ejemplo y predica con el ejemplo - asume la responsabilidad de la adopción y la práctica de Scrum

Yo quiero agregar que no es necesario obtener una certificación como Scrum Master [4], al menos no mientras adquirimos experiencia. Volviendo a la historia de los Jedi Master, Anakin Skywalker, quien sobrepasaba a varios Maestros Jedi en poder puro, nunca logró el rango de Master,  aun cuando Palpatine lo designó como miembro del Consejo Jedi antes de seducirlo hacia el lado oscuro de la Fuerza. Se cree que esto se debió a su orgullo, a su escasa experiencia y que emocionalmente era muy inmaduro. [1] ¿Algún parecido con la realidad?

Finalmente

En cualquier caso, el Scrum Master debe ser alguien con quien todos en el equipo y en la organización sientan que pueden comunicarse. Alguien que tenga la confianza del equipo y la habilidad de motivar a todos.

¡Que la fuerza los acompañe!

Referencias







lunes, octubre 21, 2013

¿Por qué fallan las implementaciones de Scrum?

Respuesta: porque desconocemos los valores y principios del Manifiesto Ágil punto
El Manifiesto por el Desarrollo Ágil de Software

La razón que expuse es apenas una de las muchas por las cuales podemos fracasar al intentar Scrum. Para hacerle frente, entonces es necesario conocer de qué se trata exactamente el Manifiesto Ágil. Este lo encontramos en http://www.agilemanifesto.org/iso/es/. Sin embargo, lo copiaremos aquí para explicar mejor el asunto que nos ocupa:

Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
Estos son los valores. Le siguen una docena de principios que pueden encontrar en la página que mencioné antes. Este texto parece inofensivo pero encierra una enorme carga emocional; sin embargo, lo más importante es que nos enseña justamente cómo debemos enfrentar los proyectos de construcción de software actuales. Y como leerlo es más fácil que entenderlo, en la sección de Referencia enumero algunos de los artículos de mi Gazafatonario IT que intentan explicar de una u otra forma la razón de ser de este manifiesto.
Algunas recomendaciones para tener éxito al implementar Scrum
  • No piense en herramientas antes que en el proceso y no piense en el proceso antes que en las personas y sus interacciones. ¿Cómo va a lograr que las persones interactúen entre sí? “La gente tiene que trabajar cara a cara” dice el mismísimo Jeff Sutherland, y para todos Scrum debe ser una forma de hacer, una forma de ser, una forma de vida. Esto es, valorar el valor “Personas e interacciones sobre procesos y herramientas” del Manifiesto Ágil.
  • Necesitamos herramientas, sí, pero no permitamos que estas nos dicten el proceso e indiquen el camino a seguir, lo último que queremos son productos de software costosos antes de lograr que Scrum funcione o antes de lograr los primeros resultados exitosos con el método. Además, necesitamos un proceso para gestionar toda una operación, desde la concepción de los productos hasta la puesta en funcionamiento de los mismos a cabal satisfacción de los usuarios/clientes; y el núcleo de ese proceso debe ser precisamente Scrum, tal y como dice la Guía, no es necesario “inventar” nada más.
  • Tampoco es necesario eliminar o agregar nada más a Scrum como marco de gestión. Por ejemplo, decir que hacemos Scrum pero no tenemos Dueño de Producto o usar el patrón proxy del Dueño de Producto, es algo común en las implementaciones deslucidas de Scrum. Uno de los principios del Manifiesto Ágil lo dice claramente: “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.” Esto apunta a resolver la mayor causa de fracaso en los proyectos tradicionales: “falta de involucramiento del usuario” [7]. 
  • No piense que Scrum le va a solucionar todos sus problemas, incluidos los personales. Scrum no es una bala de plata [4], de hecho, Scrum por sí solo no es suficiente, debe acompañarse de un conjunto de prácticas y otros métodos preferiblemente ágiles. Eso sí, no intente implementarlos todos de una sola vez y mucho menos intente hacerlo solo, hágase acompañar de expertos, de personas que hayan recorrido el camino y que quizás hayan cometido uno o dos errores críticos; con seguridad, serán ellos quienes lo sacarán del aprieto en el que posiblemente se va a encontrar más de una vez.

  • No piense en las certificaciones. Si cree que les hacen falta, estas llegarán a su debido tiempo. Cuando tenga la suficiente experiencia y madurez para darse cuenta que no las necesita. Sí, certificarse nos trae beneficios a nosotros como individuos y a las organizaciones para las que trabajamos o representamos. La certificación verifica que nuestro nivel de pericia y conocimiento es consistente con los estándares de la profesión en un área específica, pero, también a veces, las certificaciones atribuyen competencias donde usualmente no las hay, a quienes usualmente no las tienen.
  • Uno de los aspectos que hacen “mágico” a Scrum es que podemos implementarlo usando Scrum. La gran ventaja es que no tenemos que definir un proceso porque ya está definido [8]. Podemos tener una Lista de elementos a implementar (el backlog) y los separamos en sprints de 2 semanas para ir implementando gradualmente en unos pocos meses. Esto permitirá que las personas se sientan cómodas y a gusto con el cambio y se logren mejores resultados más rápidamente.

En cada Sprint de implementación de Scrum realice las ceremonias orgánicas de Scrum:
  1. Planee cada sprint de la implementación
  2. Haga reuniones diarias
  3. Al final de cada sprint revise los resultados
  4. Antes del siguiente sprint, haga una retrospectiva de lo que fue bien y lo que fue mal durante el sprint actual de implementación 

Se me ocurre que podríamos usar, para empezar, este algoritmo general de la implementación de Scrum:
Algoritmo general de la implementación de Scrum usando Scrum
Figura 1: Algoritmo general de la implementación de Scrum usando Scrum
Esta es una primerísima versión del algoritmo a “mano alzada”, escucho opiniones al respecto.
Otras Recomendaciones a tener en cuenta para asegurar el éxito en una implementación de Scrum
  • Todo el equipo debe tener un pensamiento Ágil.
  • Debe haber un alto grado de cohesión en el equipo, incluyendo a los usuarios.
  • Centrado en el usuario
  • Transparente, es decir, todos deben conocer el estado del proyecto en cualquier momento
  • Debe predominar la Cultura de la Calidad
  • Debe haber retroalimentación continua de todos los participantes
  • Manejo de riesgos conjunto
  • Se requiere disciplina
  • El equipo debe tener un experto en métodos ágiles en general y en Scrum en particular para hacer coaching y acompañamiento continuo.
  • Participe o, al menos, manténgase en contacto con otras personas que estén usando Scrum: la Comunidad Ágiles Colombia [9] es un buen ejemplo de ello; la de Ágiles Latinoamérica [10] también.

Finalmente, cuando tenga la suficiente experiencia y cuente con equipos maduros, quizás antes, atrévase a adicionar sus propios valores al Manifiesto Ágil y póngalos en práctica. Ya en la comunidad Ágiles estamos discutiendo algunos de esos nuevos valores y principios:
Experiencia efectiva sobre certificaciones retóricas
Innovación continua sobre mantenimiento de productos
Satisfacción del Cliente sobre margen de utilidad
Felicidad de las personas sobre inapetencia profesional
¿Se animan con otros? Pueden dejarme sus comentarios o ir al foro de la comunidad Ágiles Colombia y participar de la discusión. Lo encuentran en:
Referencias
Scrum – Lo Fundamental

Scrum Orgánico para Iniciantes

Vademescrum, Sección I: El Scrum Master 1

Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum

Planificación del Sprint: el primer paso para producir el máximo efecto

Gerentes de Proyectos de software, ¿una especie en vías de extinción?

Chaos Report. Standish Group. www.standishgroup.com/


Ágiles Colombia. http://agilescolombia.org/

Ágiles Latinoamérica. http://www.agiles.org/