Scrumízate
Cuando se recuerda a los grandes equipos de la historia se habla mucho del transcendente sentido del propósito. Nos centramos en la idea de que juntos formas parte de algo más grande, más fuerte y más duradero que con las propias individualidades. El propósito es sólo una de las tres patas de la ecuación.
La segunda pata en un equipo de éxito es la libertad para hacer el trabajo. La autonomía da la capacidad de decidir cómo llevar a cabo los objetivos establecidos. Puedes descubrir cómo encontramos las felicidad en un equipo en este post.
La tercera pata, y motivo de este post, es tener todas las capacidades necesarias para hacer el trabajo. Típicamente las organizaciones se han formado con equipos con funciones totalmente separadas por etapas. Simplificando tenemos el equipo de planificadores, los constructores, los comprobadores de calidad, distribuidores...
Cada uno de estos equipos debe terminar su acometido antes de que el proyecto pueda avanzar a la siguiente etapa. En realidad ningún equipo es capaz por si solo hacer que el producto salga a la calle.
A principios de los 80, los ejecutivos de Fujitsu viajaron a Estados Unidos para estudiar cómo la NASA hacía las cosas. Y decidieron implantar el mismo sistema. Este consistía en esta visión clásica de los equipos, el proceso conocido como "etapa-puerta":
- Etapa de descubrimiento: se decidía que se iba a tratar de hacer, por ejemplo un cohete para ir a la Luna, y un grupo de estrategas se ponían a fantasear como podría ser.
- Puerta: Un jefe o grupo de jefes debían avalar el proyecto, argumentando que merece la pena hacerlo. Esto se traduce a muchas reuniones.
- Etapa de dimensionamiento: el equipo de requisitos decidía que es lo que va hacer el producto. Esto se traducía a muchos documentos muy extensos.
- Puerta: Reuniones de validación de los requisitos del producto que se desarrollará.
- Etapa de planificación: Todos los documentos de requisitos son entregados al siguiente equipo que se ocupará de la viabilidad económica y el plan del proyecto.
- Puerta: Otra ronda de reuniones para aprobar el proyecto.
- Etapa de desarrollo: Etapa en la que realmente se fabrica el producto.
- Puerta: Más reuniones y aprobaciones.
- Etapa de comprobación: En esta etapa personas que no han visto nunca antes el producto ni conocen el proyecto se encargan de testear que todo es correcto y funciona bien.
- Puerta: Más reuniones y documentos para su aprobación.
- Etapa de lanzamiento: Hasta este momento no llega a las personas que realmente harán el lanzamiento.
Cuando aplicaron este proceso en Fujitsu empezó a bajar la calidad del producto final, la tasa de fallos aumentó y los tiempos de entrega se alargaron. Pronto dejaron de usarlo. La Comisión Rogers que analizaba el desastre del Challenger en 1986 afirmaba:
Da la impresión de que, por el motivo que sea, ya sea para el consumo interno o externo, la dirección de la NASA exagera la fiabilidad de su producto hasta el extremo de la fantasía.
La verdad es que los mejores equipos comparten una característica: no existe esta separación de roles. Cada equipo es capaz de hacer todo el trabajo de principio a fin. Esto ocurre en Toyota desde hace mucho tiempo, pero también en Google, Salesforce o Amazon a día de hoy.
Actualmente Salesforce cuenta con unos 200 equipos Scrum. Cuando Salesforce empezó hacían un lanzamiento importante 3 o 4 veces al año. A medida que fueron creciendo y aplicando métodos en cascada esta cifra se redujo a un lanzamiento al año, esto ocurría al 2005-2006. Para cambiarlo decidieron aplicar Scrum. Desde ese momento lanzan un nuevo producto al mercado 3 veces al año.
Salesforce busca en un equipo la diversidad de capacidades, pensamiento y experiencia. Quieren equipos generosos y autónomos, pero también que sean multidisciplinares. Quieren equipos que sean capaces de sacar un proyecto entero por sí solos. Cada equipo trabaja en un producto o proyecto.
Una buena herramienta para saber si se está consiguiendo este objetivo es la preguntarle a cualquier persona a qué equipo está. Cuando la respuesta de un especialista es su especialidad, en lugar del proyecto en el que trabaja, significa que todavía queda mucho trabajo por hacer.
Si quieres aprender a definir los requisitos de un proyecto de una forma ágil y basada en el valor añadido al producto puedes continuar con este post donde se explica como hacerlo mediante las historias de usuario.
Te ha gustado el post? No olvides en suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
