Archivo de la categoría: Project Management

Agile, Lean

La parte impredecible de una estimación

1 comentario

¿Cuanto vas a tardar en terminar esta tarea? Esta pregunta puede resultar muy fácil de responder y hacer una respuesta con una precisión absoluta, o tambien puede resultar muy dificil y dar una respuesta que nada tenga que ver con lo que al final se termina tardando.

¿De qué depende?

En tareas como las que solemos hacer los desarrolladores de software, el resultado de nuestro trabajo no es solamente el código generado sino tambien se genera conocimiento para el propio desarrollador. Para identificar qué parte del tiempo se ha utilizado para generar la funcionalidad y qué parte del tiempo se ha utilizado para generar el conocimiento sólo hay que hacerse una pregunta:

¿Qué tardarías ahora si tuvieras que repetir la misma tarea?

Ese tiempo que responderías corresponde con el tiempo usado en la generación del producto y el resto fue el usado en la generación de conocimiento.

KnowledgeGeneration

En entornos en los que el lenguaje de programación es muy conocido y el tipo de producto final se ha hecho muchas veces, hay poca generación de conocimiento y el tiempo que se tarda se puede predecir facilmente.

LowLearning

Sin embargo en entornos de innovación continua muchas veces el tiempo de generación de conocimiento es la mayor parte.

HighLearning

Realizando pair-programming se reduce el tiempo impredecible ya que la en la tarea sólo se genera el conocimiento que no tiene ninguno de los dos componentes de la pareja.

PairProgramming

Este tiempo de duración desconocida puede llevar al traste cualquier deadline. En proyectos tradicionales waterfall puede provocar que no se llegue a tiempo y en proyectos Scrum provocan que los sprints se solapen, estando varios días del siguiente sprint terminando tareas retrasadas. Una manera de minimizar su impacto es reducir la cantidad de  trabajo en curso, reduciendo el tamaño de las historias y focalizando a todo el equipo en la consecución de la misma en lugar de tener muchas historias abiertas.

Agile, Lean

Scrumban, de moda pero quizá no necesario

Nota: El Scrumban del que hablo no tiene nada que ver con el que acuña David J Anderson

Hace poco escribí un tweet en el que decía que el Scrumban no era necesario. Los 140 caracteres del tweeter no dan espacio para una explicación de esto pero voy a intentarlo aquí.

Scrumban, al menos el que conozco yo, se basa en dos paneles. Un panel con las historias de usuario del sprint, características y bugs a desarrollar provenientes del product owner, y un panel kanban con el resto de tareas que no tienen que ver con las historias de usuario previstas. Normalmente son problemas a resolver de soporte de algún cliente o relativas a otros departamentos de la empresa.

En el panel kanban se establecen 3 prioridades relativas a las tareas del panel Scrum.

  • Una prioridad llamada ASAP, en lo que se hacen tareas cuando el trabajo pendiente en el panel Scrum sea menor del ideal que tocaría para ese día.
  • Una prioridad llamada PRIO en se cogen tareas cuando se ha terminado en las que se está trabajando en ese momento.
  • También una prioridad FIRE en la que cuando se añade una tarea hay que hacerla de modo inminente dejando el trabajo a mitad. Naturalmente en la retrospectiva se analiza por qué ha ocurrido una tarea FIRE y se intenta evitar que ocurra en el futuro.

Yo veo un problema grave en el hecho que sean dos paneles con la misma función y añade gestión extra que quizá no sea necesaria. Además tener dos sitios donde mirar el trabajo es más complejo que tener uno solo en el que esté todo el trabajo que se está realizando.

Cuenta con que el Product Owner es el que pone las tareas al kanban y requiere que las prioridades sean muy claras. Tambien es una herramienta para que el equipo justifique ante el PO el haber hecho más o menos puntos de producto.  Yo nunca he entendido esta necesidad de justificación ya que todos deberíamos tener los mismos objetivos, que es dar valor a los clientes.

Yo entiendo tres prioridades que encajan en un solo panel.

  • La prioridad FIRE es que no hace falta ponerla en ningún panel, se le dice a la persona o personas involucradas que se ponen a ello inmediatamente.
  • La prioridad «lo tendrá a final de este sprint» en el que es posible que salga alguna historia que ya estuviera en el  sprint para que quepa la nueva.
  • La prioridad, «lo estudiaremos para el siguiente sprint» en el que se encajará como una historia más para el siguiente sprint dejando inalterable el actual.
Agile, Lean

Lean y Agile, dos puertas para el mismo camino

Hay muchos debates sobre diferencias entres Agile y Lean. Yo personalmente pienso que los dos tienen los mismos principios, lo único que Agile está hecho por desarrolladores para desarrolladores mientras que Lean está hecho en el ámbito de la producción y tiene un ámbito más amplio. Voy a repasar las entradas del manifiesto y veremos como van por los mismo caminos.

Individuos e interacciones sobre procesos y herramientas

Nadie mejor sabe cómo se hace mejor un trabajo que el propio trabajador. Todos los procesos que se incorporan deben ser consensuados y propuestos por las personas que tienen un trato directo con el producto.  Los cambios de herramientas deben ser estudiados concienzudamente y deben tener como único fin ayudar a la persona.

Software funcionando sobre documentación extensiva

Lean intenta eliminar cualquier tipo de desperdicio (waste) que no aporte valor al cliente. La documentación ha sido historicamente el mayor tipo de trabajo del desarrollador realiza que no aporta valor al cliente por lo que reducirlo en medida de lo posible es una manera de centrarle en lo que verdaderamente le aporta valor.

Colaboración con el cliente sobre negociación contractual

La máxima flexibilidad y poner al cliente en el centro es crucial para Lean. Además cuanta más información se tenga de él en el momento que justo sea necesario para aportarle lo que realmente necesita más valor se le dará.

Respuesta al cambio sobre seguir un plan

La observación y la respuesta rápida a los problemas es también uno de los principios importantes en Lean. Para responder rápido a los cambios, se debe ver a mayor información posible y que esté disponible para todo el mundo. También hay que responder rápido a los cambios poniendo máxima prioridad en darles respuesta.

Agile, Lean

Retrospectivas de ámbito global

Las retrospectivas  son un punto muy importante en el mundo ágil.  Es el momento de reunirse el equipo y ver cómo mejorar y adaptarse al entorno cambiante. Cada sprint es distinto del otro y tanto las necesidades del mercado, del producto, de la tecnologia y otros muchos factores cambian muy rapidamente.

En la retrospectiva hay que exponer los problemas y resolverlos por ejemplo mediante la técnica de los 5  por qués  (5 whys) o con la de la raspa de pez (fishbone). Las soluciones propuestas para resolver los problemas se añaden a la lista de tareas como tareas de proceso que se resolverán junto a las tareas de producto en el siguiente sprint. De este modo el equipo va mejorando a sí mismo sprint tras sprint siendo cada vez más productivo y más feliz.

Hasta aquí todo lo que se puede hablar (muy, muy resumido) de una retrospectiva cuando hablamos de Agile o Scrum. Pero ¿realmente ese es el objetivo final? ¿Sirve de algo tener un equipo de desarrollo que va a cientos y cientos de puntos por sprint mientras que el resto de los departamentos van como con bolas de preso atadas a sus pies? ¿Es suficiente que los desarrolladores  entren y salgan  con una sonrisa en la boca diariamente mientras que en el resto de los departamentos  sufre los mismos problemas semana tras semana? ¿Qué pasa con el departamento comercial, el de operaciones, el de soporte, el de marketing…. ? ¿No estamos todos en el mismo barco?

La perspectiva Lean dice que hay que ir mejorando el flujo de valor (desde el comercial hasta la postventa) y no sólo centrarse en una fase (desarrollo).

Cuando estuve en la Conferencia Agile Spain 2011, Xavier Quesada habló del Failure Demand. Esto es cualquier trabajo realizado a causa de algo que se ha hecho mal anteriormente. Puede ser la corrección de bug, el volver a generar una base de datos porque alguien la ha borrado accidentalmente,… Propuso algo que llevé a la practica que es poner un tablón con el titulo ¿En qué he desperdiciado el tiempo? Ahí la gente pone etiquetas como por ejemplo «4 horas ayudando a soporte a instalar el sistema». En la retrospectiva se analizan todas esas etiquetas y se buscan soluciones para que no vuelvan a ocurrir.

Esta es una idea que se puede aplicar globalmente. Cada departamento tiene su propio tablón con sus Failure Demands. Cada 2 o 3 semanas se juntan los miembros del departamento y los analizan exactamente igual que hace el departamento de desarrollo. Hay problemas que pueden solucionar por ellos mismos pero hay también problemas en los que parace que tienen que  intervenir otros departamentos para solucionarlo.

Una vez al més los directores de departamento se reunen y evaluan estos problemas que no han podido ser resueltos localmente. Entonces hablan entre ellos y deciden cómo solucionarlo de la manera más eficiente de manera global. Hay problemas que son resueltos por otros departamentos efectivamente pero tambien hay problemas que vuelven al departamento de origen, ya se ha decidido que lo más eficiente es que lo resuelvan ellos mismos.