×
×

Como planificar un proyecto a largo plazo en Scrum

¿Como planificamos un proyecto a largo plazo en Scrum? (2 de 3)

¿Qué queremos enseñar?

En esta segunda entrega de la entrevista a Jens Drachmann, hablamos sobre cómo planificaba el desarrollo del mejor caudalímetro del mundo y el rol de Jens como Product Owner, miembro del equipo de desarrollo y CEO al mismo tiempo. (Para contextualizar este contenido, recomendamos leer la primera parte de la entrevista

¿Por qué queremos compartir este caso?

Mostrar a empresas como se puede hacer una proyección a largo plazo (planificación) de un proyecto en entornos de desarrollo de producto de hardware y software utilizando Scrum.

Jens Drachmann nos explica cómo planificar a largo plazo con Scrum y su rol como Product Owner

P28_Pol-i-Jens_SM.jpg

Pol Martínez y Jens Drachmann

¿Cual era la estructura de la empresa cuando empezasteis el desarrollo de Ultrimis en todas las facetas (mecánica, electrónica, software, etc)?

Podríamos decir que teníamos una organización de empresa muy simple, donde yo era el CEO y el resto estaba por debajo. Pero al tener un equipo para el desarrollo de nuestro producto, también era el Product Owner y parte del equipo de Desarrollo. El Scrum Master que teníamos también era parte del equipo de desarrollo. Esta situación es un poco especial porque según Scrum está permitido, pero no se aconseja hacerlo de esta manera. Aún así, nosotros tuvimos que hacerlo por falta de recursos.

¿Cómo funcionaba el equipo de esta manera?

Lo que teníamos que hacer era simplemente ser muy claros sobre qué rol éramos en diferentes situaciones, cada vez que teníamos una conversación. Así que acordamos entre todos que cada vez que había una conversación entre personas con diferentes roles, tenía que estar completamente claro qué rol se escogía en esa situación. Con esto, nos funcionó muy bien. Sino, habrían muchos malos entendidos. Con el tiempo, se hizo natural en el equipo y lo seguimos haciendo hoy en día.

Cuéntanos más sobre tu rol como Product Owner, ¿Cuales fueron los principales retos?

  • Por un lado, debido a las diferentes tareas que teníamos, el PO necesita asegurarse de que hay trabajo para todo el mundo, que esté en la dirección de la especialidad de cada miembro. Que haya solo tareas de software durante medio año cuando tienes ingenieros mecánicos en el equipo, no es una composición óptima del equipo. Esto significa que el PO tiene que trabajar en la composición del equipo o utilizarlo lo mejor que pueda, siempre priorizando el valor y la calidad por encima de la cantidad. Ese es un reto muy importante.
  • Otro reto en desarrollo de producto, es mantener el Product Backlog actualizado en todo momento de acuerdo con las necesidades del mercado y/o descubrimientos tecnológicos internos y externos. Aquí el Product Owner juega un papel crucial para maximizar el valor de cada tarea, en el que debe estar en contacto constante con el cliente, el usuario final o el propio equipo de desarrollo para transferir toda esa información al Product Backlog y ordenarla.

En tu rol como Product Owner, ¿Como planificabas el proyecto de Ultrimis a largo plazo?

Para entrar en contexto, todo era nuevo en este caudalímetro, así que no tenía ni idea de cuando se iban a cumplir los plazos, pero aún así, tuve que hacer un plan para los inversores y la junta. Para mostrar progreso, siempre miraba hacia atrás (progresión de valor entregado hasta la fecha) para mostrar que había avance. Pero se van encontrando nuevas cosas que deben ser investigadas todo el tiempo mientras que estás intentando acabar un producto complejo. Así que los planes eran revisados todo el tiempo, tanto, como en cualquier proyecto tradicional. Scrum no hace las cosas más predictivas, es tan horrible como en el mundo tradicional, simplemente no puedes predecir cuando las cosas van a estar terminadas. Pero por otra parte, en Scrum no tenemos la ilusión de que podemos acabarlo en el tiempo proyectado. De la manera tradicional, creemos en que podemos cumplir los plazos. Pero por desgracia, es casi siempre falso. No hay manera posible de predecir cuando la investigación y el desarrollo de un producto nuevo están terminados. Por lo menos en Scrum, lo admitimos desde el principio. De tal manera, que cuando nos encontramos con obstáculos podemos cambiar la dirección inmediatamente. Aún así, es conveniente tener un plan para tener algo de navegación y una visión.

P27_Miitors Milestone.JPG

En nuestro caso, simplemente empezamos a trabajar en fases o "milestones". Dividimos el proyecto en fases donde en cada fase teníamos un objetivo, como por ejemplo, desarrollar un prototipo con cierto grado de funcionalidad. En cada fase, identificábamos lo que necesitábamos para completar ese prototipo a medida que aprendíamos de nuestra propia tecnología y reconducíamos el plan continuamente, adaptandolo a Sprints de 3 semanas, priorizando el Product Backlog con ayuda del equipo de desarrollo y con el input del cliente y el usuario final. Teníamos una fecha de entraga fija, un presupuesto fijo y ajustabamos el alcance hasta donde podíamos llegar dados los plazos y los recursos de los que disponíamos para cada Milestone.

 ¿Necesitas ayuda para planificar tus proyectos con Scrum?

En el siguiente post, hablaremos de la contratación de ingenieros en Miitors y de cómo transmitir la visión de la empresa.