Hoy me ha llegado un comentario en plan jocoso diciéndome: «¿cómo aplicas scrum si eres freelance y estás tu sólo en el equipo?, ¿te reúnes tú sólo contigo mismo por las mañanas?»
Y me ha hecho recapacitar en:
- La visión tan simple que tiene mucha gente de lo que es scrum y la metodología agile en general. Se piensan que aplicar Scrum, es tener un tablero bonito con un montón de post-its, y reunirse por las mañanas «un ratillo» para hablar de las tareas.
- ¿Se puede aplicar metodología agile en equipos unipersonales?
1.- Scrum, algo más que una reunión matutina.
En este punto no voy a profundizar, es más, no voy ni a entrar. Simplemente decir que se puede aplicar scrum sin necesidad de post-its, SIIII, increible pero cierto.
Y que te reúnas por las mañanas con los compañeros de trabajo para hablar de las tareas que vas a realizar, eso no es un daily, eso es hablar de trabajo mientras te tomas un café.
2.- Aplicar scrum siendo freelance.
Vamos al turrón, que es por lo que estás leyendo este post.
Siendo puristas, cualquier Scrum Master te diría que NO, que para montar un equipo de scrum, necesitamos 3 roles:
- Product owner
- Scrum Master
- Equipo de desarrollo (entre 3 y 9 personas)
Vale que scrum nos permite que el scrum master y el product owner puedan pertenecer al equipo de desarrollo, pero aún así nos siguen faltando personas.
Dado que ya tenemos el NO, ¿qué tal si apoyándonos en uno de los pilares del empirismo, sobre el cual se apoya scrum, nos adaptamos a nuestro entorno y condiciones?
Ok, somos 1, para todo, y seguro que habrá cosas de scrum que no podamos hacer, pero sí vamos a aplicar scrum en todo lo que podamos, y sobre todo sus pilares y metodología que hay detrás, seremos lo más agile que podamos.
Si uno de los pilares del empirismo nos dice estamos ante un entorno de incertidumbre, al que debemos constantemente adaptarnos, pues adaptemos incluso la metodología a nuestro entorno (que me perdonen los scrum masters más puristas). Veamos los distintos elementos:
Roles
En una sola persona se centrarán los 3 roles. Seremos:
- Product owner: Intentando maximizar el valor del producto y mirando por su interés.
- Scrum master: El scrum que apliquemos estará bajo nuestra responsabilidad y seremos nosotros los encargados de que se cumpla.
- Development team: Toca picar código también.
Como he mencionado antes, aquí no estamos cumpliendo scrum, pero … es lo que hay, ojalá el presupuesto diera para tener a un equipo al lado.
Artefactos
Backlog de producto:
Esa lista de tareas o funcionalidades que nos piden y vemos que mejora o componen al producto.
Pues nada, toca ponernos el sombrero de Product Owner y a tomar requisitos y gestionarlos teniendo siempre en mente maximizar el valor del producto final.
Sprint backlog:
Qué se va a hacer, y cómo se va a hacer lo que se ha definido para el sprint actual y alcanzar el sprint goal, podemos gestionarlo sin problema nosotros mismos, ya que nos tocará ser el equipo de desarrollo.
Incremento:
El incremento representa el alcance real, tanto de los sprints anteriores, así como lo que llevamos del actual. Nos ayudará a saber en qué estado estamos y hacer estimación de cuanto nos queda (estimación, ya que los requisitos del producto son cambiantes y puede que nos entren tareas en el product backlog antes de terminarlo)
Eventos
Veamos los eventos uno a uno:
Sprint:
Definir la funcionalidad y objetivo del producto a 1 mes vista máximo, es el principal potencial de scrum, evitando gran parte de la incertidumbre de abordar proyectos grandes y permitiéndonos ser más ágiles ante cambios. Aquí el centro es el producto, por lo que seas freelance o no, puedes aplicar la filosofía agile a tus proyectos, haciendo iteraciones de máximo 1 mes, y adaptando el producto a los nuevos requerimientos o situaciones.
Imagina que te encargan hacer una web. El procedimiento en cascada sería, hacer un presupuesto general de todo el proyecto, anotando funcionalidad y demás. Poniendo una fecha de entrega final, o a lo sumo alguna entrega intermedia.
Pues eso lo vamos a convertir en estudiar el negocio del cliente, ver el producto que desea, y maximizar el valor de los distintos requisitos tomados.
Entregaremos por ejemplo en 3 semanas una primera landing, con la que el negocio pueda por ejemplo captar leads, y nos permita ir validando nuestra web.
Pasadas esas tres semanas, volvemos a iterar, nos sentamos, recogemos feedback y vemos según lo obtenido cuales serán las tareas a abordar en las siguientes 3.
Y así hasta conseguir un producto final, que probablemente diste bastante de lo que inicialmente teníamos pensado, pero que maximiza el valor del negocio, y escucha a los usuarios finales.
Sprint planning:
Reunión en la que se definen qué tareas del product backlog se van a abordar en el sprint para alcanzar el Sprint Goal, y se descomponen dichas tareas.
Sin problema, hacemos esta reunión más solos que la una, pero podemos sin problema elegir las tareas y descomponerlas.
Sprint review:
El equipo scrum al completo ya sabemos que acudirá, ya que eres tú. Pero podrás invitar a otros stakeholders, como por ejemplo al cliente, para de forma informal, enseñarle el incremento alcanzado, ver qué vamos a necesitar del producto para añadir esa información el product backlog, y ver qué vamos a atacar en el siguiente sprint.
Sprint retrospective:
Es hora de evaluarnos, y ver en qué hemos fallado y qué podemos mejorar en el siguiente sprint. Será difícil autoevaluarnos, pero nos hará crecer tanto en el proyecto, como a nivel personal como profesional.
Daily:
Reunión diaria de no más de 15 minutos para que el equipo de desarrollo hable sobre los avances y tareas para conseguir el sprint. Fácil, ¿no? Pues eso, te sientas 15 minutos por las mañanas con un buen café y revisas las tareas del día.
Sé agile
Como puedes ver, poder se puede aplicar Scrum siendo freelance. Se trata de encontrar el grado de aceptación que consideres que te lleva a adaptarte a los cambios de forma ágil, permitiéndote sacar el máximo valor al producto.
Sé que los puristas de scrum estarán afilando los cuchillos para matarme, pero tal y como comenté al principio del artículo, empirismo en estado puro, adaptando al entorno y circunstancias incluso al mismísimo framework scrum.
>_ Be agile my friend !!