Enfermedad Mortal... La Hora Hombre

Hoy en día, donde se habla bastante sobre los beneficios del Management 3.0, la agilidad, peopleware, desarrollo de personas, los procesos y la mejora continua, seguimos encontrando empresas que trabajan como en la época industrial.

Muchas se autodefinen como ágiles, pero lamentablemente no han podido salir del Management 1.0, a lo sumo se encuentran en un Management 2.0,  combinando prácticas de gestión tradicional con algo de agilidad.

Desarrollos en cascada que comienzan por los requerimientos, pasan seguidamente a los casos de uso (incompletos e inservibles en casi todos los casos), luego al desarrollo, posteriormente al testing y si aún estamos vivos y no cambiaron los requerimientos, a la etapa de implementación, se acomodan en iteraciones y ..... listo .... ya somos ágiles.

Sigue siendo muy común por ejemplo, encontrar que la unidad de medida para estimar el trabajo que se llevará a cabo, es la hora hombre.

Trabajamos 8 horas diarias, que multiplicadas por 5 días nos dan unas relucientes 40 horas semanales. ¿Ya cargaste tus horas en el sistema de producción?

Luego multiplicamos por la cantidad de personas que conforman el equipo (sí, dije personas) y nos da la cantidad de horas para dedicar por semana al proyecto.

Eso sí, no almuerces ni tomes un café porque lo vas a lamentar. 

Pero, ¿necesitamos saber el total de horas?

¿Me sirve de algo?

¿No será mejor conocer cuanto trabajo somos capaces de hacer en un tiempo determinado?

Ahhh ¿Suena mejor no?

Claro que sí.

La hora hombre no es un buen parámetro para dimensionar la cantidad de trabajo a realizar, ya que cada persona realizará las tareas a ritmos distintos. (¿Dije otra vez persona?).

Ed Catmull, cofundador y presidente de Pixar Animation Studios, comenta en su reciente libro Creatividad S.A. que para calcular cuando va a estar listo un largometraje, utilizan como unidad de medida la cantidad de trabajo que realiza una persona en una semana (Ed dijo persona en su libro, no fuí yo).

Por tal motivo en SCRUM utilizamos estimaciones relativas. Para obtener el total de puntos de historia de nuestra pila de producto (Product Backlog).

¿Y que hacemos con eso?

Conociendo cuantos puntos hace un equipo por iteración (velocidad de equipo) podemos determinar una fecha tentativa de entrega.

Finalmente podemos ponernos de acuerdo con el cliente, y en base a sus prioridades, ordenar el Product Backlog y armar un cronograma muy básico que visualice lo que podríamos ir entregando a lo largo de las iteraciones.

Conclusión

Los directivos de las empresas deberán hacer grandes esfuerzos para mejorar la gestión de los proyectos y no quedar atrapados en un paradigma dominante que no les permitirá abrirse al cambio.

La microgestión, gestión por el miedo, gestión del tipo "dirigir y controlar", ausencia de liderazgo y estructuras verticales en las que se organizan la mayoría de las empresas, son el principal camino hacia la mala gestión.

Implementa nuevas metodologías. Los clientes, la empresa y nuestros equipos te lo agradecerán.

La importancia del Taskboard fìsico

Uno de los elementos mas importantes para visualizar nuestro proceso, es el tablero de Scrum o Taskboard. En él se refleja el estado de la iteración en curso.

Lamentablemente no todos ven la importancia de tener el Taskboard visible en la oficina y hoy en día es reemplazado por alguna de las tantas herramientas informáticas que ofrece el mercado.
He escuchado mas de una vez que nuestros Taskboards físicos están pasados de moda.

Oído en una empresa:   "Parece muy viejo eso".

Oído en otra:   "Hay que utilizar herramientas informáticas".

Dejo unas fotos de la planta de Toyota,
Si no te parece familiar, te cuento que fueron los primeros en visualizar sus procesos en sus fábricas utilizando el método KANBAN (tarjeta en japonés).

Las siguientes fotos fueron tomadas en el año 2011, en el sector de servicio técnico y retiro de unidades, en la Ciudad Autònoma de Bs As, Argentina.

¿Que te parece?

Enfermedad Mortal... La evaluación de desempeño.

Ya hemos leído bastante acerca de los roles en SCRUM. Hay mucho escrito al respecto, y en resumen sabemos que la metodología propone tres roles: Product Owner, como representante del cliente; el Equipo, quien se encargará de desarrollar el producto que el cliente espera y, el Scrum Master, quien será el facilitador del equipo y velará (entre otras cosas) para que se sigan las buenas prácticas que propone la metodología.

Uno de los aspectos mas importantes para que el Equipo funcione como tal, es la motivación.

Acá quiero detenerme para comentar algo que los japoneses ya tienen bien claro desde el año 1950 y que fue uno de los principios que el Dr Edwards Deming les enseñó. 

La evaluación de desempeño, evaluación del comportamiento, calificación por méritos o calificación anual, destruyen el trabajo en equipo.

¿Pero porqué el Dr Deming afirmaba tal cosa?

Deming denominó a esta práctica muy común de las empresas occidentales: Enfermedad Mortal, y su efecto es devastador.

Según el Dr Deming:

Alimenta el comportamiento a corto plazo, aniquila la planificación a largo plazo, desarrolla el miedo, derriba el trabajo en equipo y alimenta las rivalidades.

Deja a las personas amargadas, desechas, heridas, apaleadas, desoladas, descorazonadas, incapaces de trabajar durante varias semanas después de recibir su calificación. No es justo, ya que adscribe a las personas de un grupo unas diferencias que pueden estar totalmente causadas por el sistema dentro del que trabajan.

La idea de una calificación por méritos es seductora. El sonido de las palabras cautiva la imaginación: se paga por lo que se obtiene; se obtiene lo que se paga; se motiva a la gente a que lo haga lo mejor posible, por su propio bien, para salvaguardar su propia vida. Quien pierde es la organización.

Conclusión

Las metodologías ágiles brindan formas eficaces de gestionar los proyectos de desarrollo de software, organizar el trabajo y desarrollar los equipos de trabajo para que éstos sean mas eficientes y productivos. 

Sin duda, esto debe estar acompañado de un compromiso por parte de las empresas, para que las personas se sientan orgullosas de su trabajo.

La dirección de las empresas debería reflexionar acerca de las teorías del Dr Edwards Deming y brindar apoyo a las personas, ya sea reemplazando supervisión por liderazgo, estimular la educación y la automejora de todo el mundo y sobre todo, evaluar el trabajo de los equipos y no de las personas de forma individual. 

Referencias:

Edwards Deming "Calidad, Productividad y Competitividad, La salida de la Crisis".

Herramientas Ágiles II

Tanto si has formado parte de un equipo ágil, o si has facilitando algún proyecto de manera ágil, o si ya lo estas haciendo actualmente, sabrás que el equipo debe reunirse al final de cada iteración para proponer mejoras o cambios a implementar en la siguiente iteración o Sprint. Si. Lo antes posible. Porque queremos hacer mejor las cosas; la mejora continua o filosofía Kaizen de la que ya escuchaste hablar miles de veces. El objetivo es hacer lo que ya estamos haciendo, pero hacerlo mejor.

En scrum esta reunión se llama reunión de retrospectiva y existen varias técnicas ya probadas para lograr reuniones eficientes.

La genial herramienta creada por Corinna Baldauf  nos facilitará la elección de la técnica a utilizar.

Retromat te permitirá seleccionar de manera aleatoria una técnica, buscar una técnica por ID o buscar por palabra clave.

Considero que es excelente ya que te permitirá variar las técnicas y aprender en cada una de ellas.

La técnica de Las Galletas se vé muy divertida.

Mi favorita es La Estrella de Mar.

Te dejo el link para que la investigues: http://plans-for-retrospectives.com/index_es.html?id=27

Retromat fué traducida al español por la comunidad ágil de Latinoamérica.

Desarrollo iterativo y la mejora continua

Una de las ventajas que presenta scrum como metodología de desarrollo de software, es que el desarrollo se organiza de manera iterativa e incremental, estableciendo de esta manera un proceso que está dividido en etapas y permitiendo obtener al final de cada una un producto potencialmente productivo con las funcionalidades mínimas y mas importantes y además estable.

Dividimos entonces el desarrollo en varias iteraciones llamadas Sprints, donde al final de cada uno no solo obtendremos un producto terminado, sino que contamos con la posibilidad de mejorar nuestro proceso de una manera continua, realizando una reunión de retrospectiva para evaluar lo que ha ocurrido en el último Sprint y proponer cambios para el siguiente. Al final del desarrollo podemos también realizar una reunión para evaluar el resultado del proyecto en su totalidad.

Estos conceptos para la calidad y mejora no son para nada una novedad y no fueron utilizados por primera vez con el manifiesto ágil, ni para el desarrollo de software iterativo ideado para responder ante las debilidades del modelo en cascada.


El cíclo de Shewhart

Walter Shewhart entre 1930 y 1940 ideó una técnica para organizar el trabajo y seguimiento de proyectos de cualquier tipo.

Es un procedimiento valioso que ayuda a perseguir la mejora en cualquier etapa.
La razón para estudiar los resultados de un cambio consiste en tratar de aprender a mejorar el producto de mañana, o la cosecha del año que viene.

De esta manera, el paso 4 del circulo nos llevará a:

a) Mejorar en cualquier etapa
b) Satisfacer mejor al cliente en esa etapa.

Puede que los resultados no indiquen ningún cambio, por lo menos por ahora.
También se puede hacer un bucle entre tres o mas etapas, para mejorarlo todo estudiando la interacción de los cambios sobre una o mas etapas del ciclo de Shewhart otra vez.

Por último es importante tener presente que cualquier actividad y cualquier trabajo forma parte del proceso. Cualquier proceso dividirá el trabajo en etapas y en cada etapa hay un cliente, la etapa siguiente.
La etapa final enviará el producto o el servicio al cliente final que es quien compra el producto o servicio.

Al Ciclo de Shewhart se lo conoce también como el Ciclo de Deming ya que fue éste quien lo implementó exitosamente en Japón en 1950.



Referencias:

Edwards Deming, Calidad, productividad y competitividad. La salida de la Crisis.
1989, ediciones Diaz de Santos SA

Paradigma Dominante I

Si ya decidiste implementar Scrum en tu organización, es porque habrás escuchado o leído sobre el tema, y estas seguro de que te va a ayudar a gestionar los proyectos de manera ágil, donde los equipos de desarrollo son autogestionados, incorporando funcionalidades de forma iterativa e incremental, entregando valor en cada iteración y mejorando el proceso de desarrollo continuamente. Nada mas cierto que esto. El resultado que conseguirán en cada proyecto será notable.

Pero, para que esto suceda, deben darse algunas condiciones. Scrum es bastante fácil de aprender y bastante dificil de implementar.
Esto es cierto, y en algunos casos costará más y en otros casos costará menos.

¿Donde puede estar entonces el inconveniente?
¿Acaso no todos los que implementaron scrum lo hicieron de manera exitosa?
La respuesta es no.

El primer impedimento que tendrás que enfrentar a la hora de implementar Scrum o alguna otra metodología, y que nadie te ha contado, es el Efecto Paradigma.

Los paradigmas son ideas, pensamientos y creencias incorporadas que se aceptan como verdaderas o falsas sin ponerlas a prueba de un nuevo análisis.

El problema está ocasionado por lo que se denomina Paradigma Dominante y se refiere a los valores o sistemas de pensamiento en una sociedad estable, en un momento determinado.

Para muchas organizaciones, su concepción de paradigma se acerca al de cultura organizacional, ya que se refiere a la forma como se han venido haciendo y se hacen las cosas aquí y a la forma como se seguirán haciendo.

En la próxima entrada te contaré las condiciones que facilitan que un sistema de pensamiento pueda convertirse en un paradigma dominante y poder así Romper ese paradigma.

Estimaciones ¿Por qué terminan siendo incorrectas?

Mientras participaba en una discusión sobre prácticas en gestión de proyectos de software, surgió el tema que nos afecta a todos y que parece no tener solución.
Tanto si formas parte de un equipo de desarrollo como si gestionas proyectos de software, te has tenido que enfrentar con las estimaciones, que por lo general terminan siendo incorrectas.

Según Shari Lawrence Pfleeger en su libro Ingeniería de Software teoría y práctica, hay muchas razones por las que se hacen estimaciones incorrectas.
Una investigación llevada a cabo en 150 empresas, indica que el 35% de los gerentes afirmaron que las estimaciones fueron insatisfactorias por las siguientes causas:

- Pedidos frecuentes de cambio por parte de los usuarios
- Tareas pasadas por alto- Pérdida de comprensión de los usuarios de sus propios requerimientos
- Análisis insuficiente cuando se desarrolla una estimación
- Pérdida de coordinación del desarrollo de sistemas, servicios técnicos, operaciones, administración de datos y otras funciones durante el desarrollo
- Pérdida de un método adecuado o guías para la estimación

Incluso se menciona el tema de los costos ocultos, por ejemplo que a veces se necesita un mínimo de espacio y silencio para trabajar, no recibir llamadas, visitas, etc, etc.

Todas las metodologías que se utilicen para estimar, ya sean los 38 factores de productividad de Walston y Felix, el metamodelo de Bailey y Basili, COCOMO I y COCOMO II de Barry Boehm e incluso las estimaciones en puntos de historia para nuestros proyectos ágiles, requieren de experiencia acumulada. O sea, muchos proyectos que el equipo haya realizado junto.

Todavía recuerdo cuando estimamos nuestro primer proyecto con Planning Poker asignando puntos de historia. No teníamos la menor idea de cuantos puntos ponerle a cada historia de usuario.En el segundo proyecto ya arrancamos con las métricas de velocidad del primero. En el tercero fue aún mejor.

Es cuestión de experiencia y sobre todo tener presente que las estimaciones en equipo son siempre mas precisas que la estimación de un solo experto.

De todas formas voy a diferir con uno de los puntos mencionados en el libro.
No creo que un problema se deba a que los usuarios no saben lo que quieren o a la pérdida de comprensión de sus propios requerimientos, ya que es nuestra tarea guiarlos para que se puedan bajar correctamente sus necesidades y transformarlas en requerimientos.

¿Que opinan ustedes?