🈶 🤝 🗒️ Sellos y Scrum 🙏 🧑🏽‍🤝‍🧑🏻 🤦🏿

Introducción

Dio la casualidad de que con el tema ágil y scrum tengo sentimientos largos y tiernos. Todo comenzó como un estudiante: nuevas empresas con una completa falta de experiencia, pero con los ojos ardientes, el programa de preaceleración del IIDF, conferencias geniales con oradores celestiales. Como suele ser el caso con las startups: nada surgió de nuestras ideas, pero por mí mismo aprendí lo principal: una empresa puede (y en algunos casos debería) ser flexible.

Desde entonces, ha habido muchas cosas interesantes en mi vida: 3 años de experiencia introduciendo de manera remota metodologías flexibles con cinco colegas de ideas afines, trabajando como scrum master en una empresa de TI para más de 2000 personas, innumerables libros y conferencias, un par de proyectos muy pequeños y ... abriendo un kotokafe. Aquí hablaré sobre el último punto con más detalle.

Cómo empezó todo

En la fuente se encontraban 3 entusiastas sin experiencia práctica en negocios, pero con la idea de hacer una lucha contra el café con gatos. El proyecto es principalmente social: para el alma y el placer, por lo que el objetivo principal era la autosuficiencia. Sobre la ola de entusiasmo, se elaboró un plan de negocios, se calcularon las inversiones, el punto de equilibrio, etc., pero tan pronto como se concretaron las ideas, el trabajo tradicionalmente se desaceleró ...

"¿Por qué necesitamos tu ágil?"

Mi esposo (uno de los tres entusiastas) me hizo una pregunta sobre mis tímidos intentos de acelerar un nuevo proyecto. "Ya sabemos qué hacer, ¿por qué necesitamos reuniones adicionales, y eso es todo?" - Por cierto, este es uno de los problemas más populares cuando se introducen nuevos enfoques de trabajo, relevantes tanto para las empresas de TI como para las que no lo son, así que recuérdenlo.

Una forma de resolver esta objeción es mostrar las perspectivas de desarrollo (más precisamente, estancamiento) con el enfoque actual. Bueno, cuando hay 3 organizadores en un equipo, casi inevitablemente todos querrán trasladar la responsabilidad a otro. Así que en unas pocas semanas no nos hemos alejado demasiado del suelo. La autoorganización no funcionó. Tuve que ayudarla.

La mejor opción es cuando el propio equipo logró sentir el "dolor" por la falta de un único enfoque unificado para trabajar y acudió a usted en busca de ayuda. Pero en este caso, no esperé el momento en que la intervención ya sería vital, ya que yo mismo formaba parte del equipo. Mi segundo intento de sugerir "utilizar algunas de las prácticas e ideas de ágil y scrum" funcionó mejor.

Qué pasos hemos tomado en esta etapa:

Comenzamos y priorizamos la acumulación de tareas.

Primero, identificamos los principales bloques de tareas (búsqueda y alquiler de locales, reparaciones, marketing, diseño, etc.), luego ya pintamos cada uno de los bloques para tareas individuales y determinamos el orden de su ejecución. Este simple paso ya ayudó a restablecer el orden en la cabeza y hacer estimaciones aproximadas de los términos.
Establezca el ritmo de interacción

Un hecho obvio: la preparación de una acumulación de pedidos en sí misma no garantiza el logro de los objetivos. Sin embargo, debo admitir que pasaron al menos varias semanas entre la creación de una cartera de pedidos y el inicio del ritmo de trabajo. Al principio, ingenuamente esperábamos que todos simplemente tomaran algunas tareas de la lista por su cuenta y las hicieran. Pero no funciona así. Al menos en la mayoría de los casos.

Así que tuvimos una reunión en la que se tomó una decisión:

Determine el día y la hora de las reuniones regulares (en esencia, establezca la duración de las iteraciones). En nuestro caso, acordamos iteraciones de 1 semana de duración. Estas reuniones no se movieron y no fueron canceladas.
Cree reuniones en el formato: demostración de resultados de trabajo + intercambio de comentarios + tareas de programación para una nueva iteración con el nombramiento de los responsables.

No utilizamos una terminología especial, aunque las reuniones en sí recuerdan mucho a un montón de scrum: revisión de sprint + retro + planificación de sprint. De hecho, fue una reunión completa con una agenda predeterminada, que cerró la iteración anterior y comenzó una nueva.

Una vez hecho todo esto, pudimos predecir mejor el momento, no olvidar nada y no matarnos en la etapa de lanzamiento (que, por cierto, es muy importante).

De "nosotros y ellos" a "nosotros"

La siguiente etapa fascinante llegó en el momento en que comenzamos a discutir el enfoque para trabajar con empleados y contratar a estos mismos empleados.

Para empezar, era importante entender entre nosotros: cómo exactamente queremos construir el trabajo en equipo. Al principio, uno de los futuros líderes expresó su deseo de mantener una distancia con los empleados: "Como saben, pero me gustaría que me contacten por su nombre y patronímico". Recuerdo cómo en este momento me ahogué nerviosamente. Tal vez porque teníamos 25 años, o tal vez porque no sabía el segundo nombre de ninguno de mis líderes anteriores. "Y para el trabajo, les prepararemos instrucciones para todas las ocasiones". Todo esto no encajaba con mi idea de cómo trabajar.

Quería formar un equipo pequeño pero fuerte donde las relaciones se construyeran sobre el respeto y la confianza mutuos. Para que los empleados se sientan cómodos y seguros. Así que en esta etapa también tuvimos que trabajar en este momento: pasar del enfoque "Soy el jefe, eres un tonto" al enfoque "trabajaremos en un equipo". No fue tan simple, llegamos a esto a través de largas conversaciones y una búsqueda de la raíz de los problemas. Ahora me parece que las opiniones de cada uno de nosotros sobre cómo construir relaciones con los empleados fueron determinadas por la cultura corporativa en la que todavía hervíamos. Las startups criaron a alguien y alguien trabajaba en fábricas. Pero transferir el cultivo de la planta en Kotokafe no es del todo cierto.

Es importante recordar que nuestros empleados potenciales tenían cierta experiencia laboral a sus espaldas. Y si ya se habían acostumbrado a "usted es el jefe, soy un tonto", entonces para ellos el trabajo en equipo sería estresante. Por lo tanto, al elegir empleados, nos centramos en la similitud de puntos de vista e ideas, la capacidad de comunicarse y un enfoque para resolver tareas no estándar. Además de las preguntas habituales, propusimos situaciones problemáticas a los solicitantes y evaluamos las soluciones que propusieron. A lo que no prestamos atención: diplomas, medallas y otras insignias. Como resultado, elegimos la estrategia correcta y tomamos el equipo de chicos realmente geniales con los que fue fácil construir más trabajo.

"¿Por qué es ágil con los empleados?"

“Ok, Katya, la lista de tareas y reuniones generales nos ayudó en la apertura. Todos los días realizamos tareas no estándar y necesitábamos compartir los resultados. Pero, ¿qué tiene que ver el personal con eso? Tendrán el mismo tipo de trabajo, una vez que se les enseñe, y en la batalla ". - Me preguntaron sobre esto cuando ya estábamos abiertos, y surgió la pregunta sobre cómo construir más trabajo.

Y no discutí. Pensé: “Pero qué, hay lógica en esto. Deja que todo vaya como debería. Además, pasamos las primeras semanas juntos "en el campo", junto con los empleados: depuramos procesos, compartimos experiencias, nos capacitamos y los capacitamos, y recopilamos comentarios.

De hecho, todo funcionó muy bien. Los empleados están motivados, no hacen malabarismos, los gatos y los invitados están satisfechos, cualquier problema se resuelve rápidamente: la imagen perfecta. Y todo fue perfecto. Hasta el momento en que nos fuimos de vacaciones un mes después de la apertura. Durante dos semanas trabajamos solo en el formato de respuestas a preguntas urgentes en un chat de trabajo. Y cuando regresamos, descansados y felices, en el kotokafe nos encontramos con empleados deprimidos y confundidos. "No nos dejes de nuevo, por favor", preguntaron lastimosamente.

Tomamos las mejores prácticas y aplicamos en el trabajo.

Así que fuimos a la primera retrospectiva del equipo. No presentaron artificialmente una nueva reunión, sino solo cuando se dieron cuenta de que era necesaria.

Durante más de una hora, discutimos qué problemas enfrentaron los empleados, que sin embargo funcionaron bien, y como resultado hicimos una lista de pasos de mejora. Y a todos les gustó este formato de interacción, por lo que se decidió realizar retrospectivas cada 2 semanas.

Más tarde, se agregaron a las retrospectivas mini informes diarios de la mañana en el chat de trabajo. Usualmente estaban en forma libre y contenían la siguiente información: planes para hoy; Ante tales y otros problemas, aplicó tal y tal solución, funcionó / no funcionó; Necesito algún tipo de ayuda (urgente / no urgente). Deje que la palabra "informe" no lo asuste, de hecho, esta información fue igualmente importante para nosotros y nuestros empleados. Para nosotros es una oportunidad de estar al día, para los empleados es una oportunidad para resaltar problemas. Este formato era algo similar al scrum diario, aunque se adaptó a nuestros detalles.

Entonces, diariamente, resolvimos problemas actuales, una vez cada 2 semanas consideramos ideas para mejorar los procesos de trabajo. ¿Por qué no agregamos, por ejemplo, revisiones de planificación y sprint? Sí, porque no tendrían ningún sentido. Tomamos solo aquellas prácticas que eran realmente aplicables y útiles en nuestro caso. Y sí, ninguno del equipo usó las palabras "ágil" y "scrum" en el flujo de trabajo porque:

La aplicación de prácticas de scrum individuales no le da derecho a llamar scrum a su flujo de trabajo.
El nombre no es importante, el objetivo es importante. Y la esencia de todas nuestras reuniones se redujo a un proceso de mejora continua. Y todos sabían sobre este objetivo.

¿Qué pasó después?

Y luego gradualmente llegamos a una autonomía casi completa kotokafe. Los empleados aprendieron todo lo necesario para trabajar. Hicimos lo que queríamos: les dimos libertad a los empleados, respetamos sus opiniones, los apoyamos. En respuesta, se convirtieron en la fuerza impulsora detrás de este lugar: iniciaron el cambio, propusieron y promovieron sus ideas.

En relación con la mudanza, nos vimos obligados a vender una kotokafe. Ahora tiene otros dueños, el negocio sigue vivo, los gatos continúan deleitando a los invitados, y esto es realmente genial.

Eso es solo los empleados que se fueron un mes después del cambio de liderazgo. Dicen que después de nuestra partida ya no quiero trabajar "de manera diferente". Y ahora seguimos en contacto con ellos. Porque el equipo es la segunda familia.

Y en qué casos no es necesario aplicar Scrum, lea en mi otro artículo“Scrum no te ayudará. Entendemos por qué " .

Sellos y Scrum