Reflexión: Metodología ágil SCRUM en Pymes

Antes de aplicar en SCRUM es bueno reflexionar sobre lo aprendido, así que en este post vamos a contar la experiencia actual en nitsnets | studios y cómo se organizan en nuestra empresa los equipos de desarrollo.

Veremos cómo nos va a ayudar SCRUM y lanzaremos unas preguntas para expertos de SCRUM tales como ¿es SCRUM aplicable a pymes que sólo tienen un equipo de trabajo y muchos proyectos pequeños?

Primero, quería poneros en contexto con una explicación sobre cómo funcionan actualmente los procesos de desarrollo en nitsnets | studios. ¿Utilizamos SCRUM y no lo sabíamos? ¿Al ser pequeños lo aplicábamos de forma intuitiva después de muchos desarrollos? Realmente no pero aún así existen muchas similitudes. Supongo que esta forma de trabajar es similar a la vuestra:

• 1. Briefing/especificación del cliente.
• 2. Análisis del proyecto por el jefe de proyecto.

  Con estos dos puntos tendríamos un Product Backlog pero en versión light, ya que sólo el director de proyecto y cliente lo tocan, no todo el equipo.
  Los tiempos los especifica el director del proyecto las tareas se desacoplan en el sentido de que en ciertas situaciones parte del equipo no sabe lo que hace el otro. Si no se llega al tiempo quizás pueda ser problema de la especificación y no del desarrollador, que además carece de una visión global del proyecto. Aquí creo que es donde esta el mayor problema y con SCRUM se puede solucionar!

• 3. Desarrollo. Perfiles.

  Aquí el perfil es prácticamente el mismo: Product Owner sería nuestro Director o el que habla con cliente (en grandes empresas, sobretodo de publicidad, este perfil se denomina Cuentas), el ScrumMaster seria nuestro jefe de proyecto (o product manager) y el Team serían los desarrolladores. Sucede en proyectos pequeños que el jefe de proyecto también es desarrollador e incluso en los muy pequeños se encarga una única persona de ser un auténtico ScrumMaster++ (Product Owner + ScrumMaster + Team) todo en uno…

• 4. Desarrollo. Reuniones.

  Al inicio del proyecto y cuando surge alguna dificultad. Obviamente aquí no lo aplicamos bien y solucionaría muchos de los problemas planteados en los puntos 1 y 2. Hay personal que lo soluciona todo con reuniones y más reuniones, yo no creo tanto en eso ya que se interrumpe constantemente el workflow… pero como reuniones breves como plantea SCRUM creo que puede ser un acierto.

• 5. Desarrollo. Sprints

  Las entregas finales siempre tienen dos fechas: beta y producción. El tema es que solemos partir las funcionalidades en tareas y con el gestor de tareas / emails con las tareas / partes de trabajo, los jefes de proyecto hacemos un seguimiento continuo y casi diario de cómo va todo. Esto hace que no haya tareas de más de 2 días. Es como el SCRUM pero encarrilado, hace trabajar demasiado a nuestro jefe de proyecto y el desarrollador muchas veces va «ciego» al no tener una visión global del proyecto. Nuevamente parece que SCRUM lo mejorará.

Lo curioso del tema es que muchas empresas grandes (incluso las que tienen departamento de desarrollo online) contratan a pymes como nosotros para realizar desarrollos, formando así equipos de desarrollo conformados por grupos pequeños de personas. Con lo cual me lleva a pensar: ¿Seremos su forma de aplicar metodología ágil SCRUM? ¿Y por eso funcionan tan bien las subcontratas?

¿Que pensáis? ¿Trabajáis con SCRUM? ¿o al menos os recuerda a vuestra forma de trabajo?

Y otras cuestiones que rondan mi mente: ¿es posible utilizar SCRUM en equipos de trabajo pequeños que lleven unos pocos proyectos a la vez y muchos más en mantenimiento? Obviamente eso entorpece los sprints. ¿Tal vez es que SCRUM directamente no es aplicable a Pymes pequeñas de entre 3-10 empleados que tienen multiples proyectos a la vez? Adelante SCRUM Masters! 😉

En unos meses os contaremos nuestras experiencias sobre estos métodos (esperamos que) bien aplicados en nuestro proyecto estrella. #gogogo

Etiquetas: desarrollo ágil, empresa, metodología de trabajo