SCRUM se ha vuelto tan popular que ahora están tratando de implementarlo en casi todas partes. En las grandes empresas, a veces resulta que SCRUM se implementa por el bien de los informes, o para ser "progresivo" y "de moda". Como resultado, la situación, que parece ser un gerente responsable, establece la siguiente marca de verificación, dicen, fue necesario implementar la metodología, implementada, bien hecha, pero en lugar de algunas mejoras cualitativas, aparece el llamado "Zombie SCRUM" en la salida. Esto es cuando el marco se implementa formalmente, pero nadie trabaja normalmente en él. De ahí el nombre.
Mi nombre es Oleg Egorkin, soy un entrenador ágil en Rostelecom, y en esta publicación explicaré por qué surge el "zombie scrum" en general, cómo evitar esto y cómo asegurarme de que todo esté listo para que la compañía lance un equipo scrum.
Enfoques existentes para ejecutar comandos
A veces intentan lanzar un equipo scrum en TI, es decir, de abajo hacia arriba. Esto es cuando los propios desarrolladores y los jefes de departamento entienden que es hora, para este producto necesitamos una cicatriz. La ventaja es que la iniciativa proviene de las personas en el tema. Menos: con este enfoque, las empresas no están involucradas. Y si el negocio no está involucrado, entonces la estructura organizativa en sí misma con este enfoque cambia muy ligeramente o (más a menudo) no cambia en absoluto. Como resultado, la probabilidad de que dicho scrum se convierta en un "scrum zombie" es muy alta. Por supuesto, no será tal que el primer día todo saldrá mal como a uno le gustaría. Pero después de unos seis meses, las personas se darán cuenta de que todos los inconvenientes que se produjeron al inicio no fueron a ninguna parte. De ahí la frustración que siempre afecta tristemente al producto.
Hay una historia inversa, de arriba a abajo. Tampoco es lo que hay que luchar. Como ejemplo, recuerde que, hace varios años, en los albores de Agile, se lanzaron 50 equipos nuevos en un banco verde siguiendo las instrucciones de las altas autoridades, y para fines de año - 5000. Este es el enfoque de scrum por el bien de scrum. ¿Qué pasa en este caso? La gente se apresura a hacer mandados. Debajo de la pantalla, todo lo que no está atornillado comienza a remar. Scrum en esta historia nunca es una mejora de desarrollo y nuevas metodologías, es solo una marca en el KPI del gerente. El resultado es un "zombie scrum".
Y hay un tercer enfoque: la iniciativa es codireccional de arriba a abajo. Tuvimos suerte, y en Rostelecom hace un momento. Una cosa en qué. En el nivel de alta dirección, hay una asistencia constante a todos los enfoques de transformación en equipos. Al mismo tiempo, nadie establece planes "ambiciosos".
Para empresas grandes y muy grandes, esto no es del todo familiar. Funciona de esta manera: una vez al mes doy un entrenamiento básico de un día sobre Agile. Tanto los empleados de TI como las personas de negocios asisten a las capacitaciones, 25 personas en el grupo. Trato de hablar sobre ello lo más ampliamente posible y ampliamente. Después de un tiempo (puede llevar de una semana a varios meses), los colegas, al asimilar el conocimiento adquirido, regresan con una solicitud comprensible para crear un equipo scrum.
Sobre la lista de verificación
Hay dos tipos de solicitudes para mí: lanzar un equipo como parte de la transformación de un producto existente o un equipo para un producto nuevo. Para procesar estas solicitudes, escribí una lista de verificación especial, con la ayuda de la cual verifico todas las condiciones necesarias para ejecutar. Si la aplicación no pasa por ningún punto y no cumple con los requisitos preliminares, entonces no ejecutamos el equipo. Esta es una necesidad reconocida: si francamente obtiene al menos uno de los puntos y dirige el equipo sin él, aún no obtendrá resultados. Bueno, además del hecho de que no débil desmotiva a todos los participantes.
Si alguien de TI viene a mí con una aplicación, le pido que hable con el negocio y vuelva a estar juntos. Porque los negocios en Agile son un componente clave. Desde aquí tenemos el primer elemento de la lista de verificación:
1. El equipo ágil debería querer crear un negocio
Aquí, como con los vampiros, no pueden simplemente tomar y entrar a la casa, deben ser invitados. Con los entrenadores ágiles, lo mismo, en el sentido de que se debe solicitar un cambio.
Las personas de negocios y de TI notan que algunos productos funcionan en condiciones de mercado difíciles, se contactan conmigo y dicen: el enfoque debe cambiarse. Y aquí, si tienes mucha suerte, entonces la solicitud llega al principio, cuando todavía no hay un equipo, pero hay una idea bajo la cual las personas pueden comenzar a reunirse. Al mismo tiempo, todos entienden que no se puede formar una especificación clara para el producto, cambiará según el modelo de negocio, y no está claro qué modelo funcionará y cuál no.
En general, es muy importante que el negocio esté involucrado.
También es importante que el impulsor de esta participación sea algo tangible y no solo exagerado. Por lo tanto, verifico que los motivos del negocio caen aproximadamente en lo siguiente:
- reducir el tiempo de comercialización si este indicador es demasiado grande;
- aumentar la eficiencia del trabajo en equipo;
- aumentar la capacidad de gestión frente a las prioridades cambiantes.
Si alguno de estos tres puntos es, entonces todo está bien, esta es una señal segura de que el equipo comienza con las expectativas adecuadas.
2. Debe haber un producto para el lanzamiento
En primer lugar, esto es lógico. Es una tontería dirigir un equipo de producto para un producto cuando no tienes un producto. Y no importa lo que todos comencemos a hacer al respecto: alrededor de un producto o servicio.
3. El propietario del producto debe tener una visión y una hoja de ruta para el desarrollo.
Además, la hoja de ruta para un año de anticipación es mínima, en la forma del más alto nivel de comprensión de lo que generalmente deberá hacerse. Incluso si una persona tiene 3-5 hipótesis sobre qué modelos de negocios aplicará, qué quiere explorar. Si veo que hay una hoja de ruta, continúe.
4. Las empresas deben tener dinero
A saber, el presupuesto para un equipo multifuncional. Porque el producto debe ser contratado por un equipo de tiempo completo, y el negocio debe estar listo para pagarlo en el horizonte con aproximadamente un año de anticipación. Me aseguro de que todo se haga, miro qué centro de responsabilidad financiera está involucrado en esto, para que no resulte que hay una idea, hay un deseo de lanzar un equipo, pero no hay dinero.
5. Debe ser el dueño del producto en el negocio
El dueño No los dueños. Un dueño
Una persona que está 100% dedicada a este producto en particular. Hubo un caso en el que dos gerentes vinieron y dijeron: queremos crear un producto motivacional y educativo (algo tan interno para los empleados). Les digo, genial, pero ¿tienes un dueño de producto? Responden: sí, por supuesto, un propietario del producto es para capacitación y el otro para motivación. El producto es motivacional y educativo.
En ese momento, pedí pensar y acordar quién sería responsable de todo el producto. Esto resultó ser un asunto muy difícil y el equipo logró ser lanzado solo seis meses después.
Un producto: un propietario del producto. Esto es importante
6. Todos los participantes en el equipo de desarrollo también deben estar 100% asignados para el producto.
Si alguien del equipo de desarrollo trabaja al 50%, 30%, 10%, esto no es inmediato. Uno debe estar completamente en el producto. Pero al mismo tiempo, no necesito la presencia de equipos que comparten el edificio. En nuestras condiciones, es una rareza, Rostelecom es muy grande, tenemos muchas filiales y filiales (filiales filiales), donde trabajan los desarrolladores incluidos en los equipos. Y pueden extenderse por Moscú, Peter, Krasnodar y otras ciudades de nuestra inmensa patria. A veces es difícil y lento reunir rápidamente un equipo en Moscú, pero a menudo no funciona en absoluto.
Por lo tanto, sigo adelante, pero hay un requisito contrario: que el equipo se reúna durante los primeros 2 días cuando el entrenamiento está en progreso, y luego cada seis meses para mantener contactos personales y discutir temas actuales.
7. Método de pago del producto
Esto también es algo importante, así como mucho relacionado con el dinero. Cuando el propietario del producto tiene un presupuesto, se gasta a pedido. Es decir, TK está escrito en la orden, se lleva a cabo una evaluación para su implementación, y luego se asignan fondos en el presupuesto para este caso. Eso suena facil. Pero hay matices.
Cuando cambia al trabajo personalizado, al final de la ejecución de las órdenes debe haber procedimientos para aceptar y transferir el producto a la operación. Y dado que TK ya ha sido aprobado, es extremadamente difícil hacerle cambios. Cualquier edición debe ser renegociada, aprobada. Este es un proceso muy complejo y lento, incompatible con una reacción rápida a los cambios.
¿Qué hemos hecho para no enterrarnos en esto y no volvernos locos?
Puede trabajar en Tiempo y materiales cuando se concluye un contrato y se paga el tiempo de todo el equipo. Es decir, hay un equipo que trabaja para el propietario del producto. Sus servicios se pagan mensualmente o trimestralmente. Pero en nuestro país esto no se puede hacer en su forma pura, porque existen restricciones burocráticas.
Por lo tanto, comenzamos a trabajar como parte del desarrollo personalizado a nivel de pedidos trimestrales con hojas de ruta fijas (no TK), mientras que la orden no detalla cómo se implementará la hoja de ruta. El propietario del producto tiene la flexibilidad de la generación de pedidos pendientes. Y cuando termina el trimestre, descargamos de la dieta una lista de tareas realizadas y, sobre la base, formamos actos firmados y pagados. Resulta el mismo tiempo y material.
Y aquí no es necesario cumplir claramente con TK, porque no hay TK. Los requisitos que ya no tienen sentido después de probar hipótesis simplemente no se pueden hacer.
8. El equipo no debe tener ningún KPI, excepto los asociados con el producto.
Es importante precisamente porque los desarrolladores son contratados por subsidiarias, donde los KPI están acostumbrados a configurar el reciclaje (esto es cuando el desarrollador debe estar constantemente ocupado con algo). De hecho, casi todos los integradores trabajan de esta manera: en las condiciones de escasez de un proyecto (o proyectos competidores) del mismo desarrollador, pintan en varios proyectos. Y luego, para que la compañía esté en el negro, ponen al desarrollador en KPI para que siempre esté ocupado al menos en un 85%. Es decir, en realidad tiene un cierto KPI, lo que lo motiva a encajar en el número máximo de proyectos para adaptar su disposición a los números requeridos.
Afortunadamente, el equipo scrum no tiene esa necesidad (de hecho, es 100%). Me aseguro de que los equipos no tengan otros KPI además del supermercado.
Total
Esta es mi lista de verificación. Según esto, verifico todos los equipos antes de comenzar, y dado que tenemos un enfoque codireccional, puedo exigir un cambio en las condiciones si el equipo no pasa por al menos uno de estos puntos. Por lo tanto, la salida es solo aquellos equipos que están listos para implementar los valores del enfoque ágil.
Si la solicitud para el equipo pasa por todos estos puntos, comienza la siguiente etapa: capacitación y lanzamiento del equipo.
De lo que hablaré en la próxima publicación =)