Monthly Archives: julio 2009

Management rewired para PMs o Scrum Masters

Hola

Por fín terminé el libro “Management Rewired” de Charles S. Jacobs. Es un libro que recomendaban para los jefes de proyecto y esa recomendación no estaba nada mal encaminada.

El libro trata de cómo los avances en neurologia y los escaneres de actividad cerebral pueden dar explicaciones a cómo funciona el mundo dentro de las empresas. Todos nos guiamos por estímulos externos que intepretamos internamente según nuestro estado de animo o historias anteriores que hayamos pasado. Lo que puede parecer un regalo para unos, para otros puede parecer una patada en el culo. Además no se queda sólo diciendo lo que no funciona sino que acaba cada capitulo dando un recetario de cómo se debería hacer las cosas para usar este conocimiento a nuestro favor.

Un hallazgo muy importante es que el feedback, tanto positivo o negativo no funciona. El dar una recompensa por un buen trabajo o una critica casi nunca dan el resultado esperado. En lugar de esto recomienda hacer que sea la propia persona la que tenga datos objetivos suficientes para saber si lo está haciendo bien o mal. Esto coincide con lo que promulga la metodologia agil y el scrum en concreto. Dejar que el equipo sea autogestionado y darle toda la información necesaria para ello.

La organizacion también es un punto importante del que hace mención. Dice una cosa muy curiosa que es la lucha interna que existe en nosotros y nuestra vida en la empresa ya que segun los genes que tenemos de nuestros antepasados los hominidos, luchamos individualmente por llegar a ser el macho alfa (el jefe supremo), sin embargo, necesitamos trabajar en grupos para conseguir objetivos mayores que los que puede conseguir uno mismo. Recomienda el organizarse en pequeños grupos “autonomos” para que se pueda combinar la fuerza de ambas fuerzas. Coincide con cómo funciona el scrum, organizando en grupos de 7 personas más o menos.

Según el autor, el tipo de lider que hace falta para obtener el mejor resultado no es uno que ordene sino uno que pregunte. Una pregunta concreta puede mover a una persona con mucha mas motivacion y resultado que cualquier orden. Coincide con el scrum con el hecho de que cada día se hacen las preguntas del daily scrum (qué has hecho, qué vas a hacer y qué necesitas para hacer tu trabajo).

En fin. Es un libro que ha superado mis espectativas y contiene un conocimiento que no hay que dejar escapar

Anuncios

Nuevos roles en proyectos software

Ultimamente he podido identificar dos roles que son importates para la realizacion exitosa de los proyectos software. Voy a usar la analogia del rugby igual que se hace con el scrum.

Entrenador: Aunque se puede confundir por el scrum master, tiene un papel distinto. Hay proyectos, sobre todo cuando es trabajar sobre una aplicacion ya existente, que necesitan un conocimiento profundo de su arquitectura. Ese conocimiento puede tenerlo una persona que no está dentro del equipo de desarrollo. Esto ocurre por ejemplo en empresas de software en las que empezaron pocos programadores y esos programadores pasan a llevar cargos de gestión cuando la empresa crece.
El entrenador participa en las estimaciones como uno más del equipo. Cuando se usa poker planning, el entrenador tiene una baraja ya que su opinion sobre lo facil o dificil de una tarea en particular es muy importante. Si hay discrepancia entre el equipo y el entrenador se puede optar por la mayor de las estimaciones o la del equipo, que es realmente quien se compromete en esa estimación.
El entrenador participa en los daily scrum. Si hay algo de lo que ha hecho el equipo que puede dar problemas el entrenador lo detectaria en ese momento y actuaría sin tener que esperar a estar en las fases finales para descubrir ese problema.
Puede participar como pair programmer cuando se necesite, sobre todo cuando los deadlines son ajustados y se va con retraso.

Defensa: Esto más que un rol continuo es un rol que cada miembro del equipo puede ir asumiendo una o varias veces durante un sprint. En rugby el defensa va protegiendo a quien tiene el balón para que vaya lo más rapido posible. En un proyecto software el defensa va asumiendo las tareas de mantenimiento urgente que puedan venir de incidencias de cliente.
Hay momentos en el proyecto en el que todos los miembros del equipo no pueden trabajar a la vez directamente en el mismo codigo fuente. Cuando esto ocurre esos programadores actuan de defensa. Evitan que los que sí que estan trabajando directamente en el proyecto no tengan que dedicarse a otro desarrollo urgente.