Vez tras vez me encuentro con organizaciones convencidas del valor de Scrum como herramienta para el manejo efectivo de incertidumbre (y por lo tanto del riesgo) en los proyectos de software.
Sin embargo, una queja reincidente entre mis colegas en el campo de agile coaching & training es que:
- Se contratan Administradores Tradicionales de Proyectos para el puesto de ScrumMaster.
- Se contratan ScrumMasters solo porque recibieron un taller o curso de Scrum.
En este artículo hablaré sobre las aptitudes y actitudes que un verdadero ScrumMaster satisface cuando se quiere obtener los verdaderos beneficios de Scrum, a saber: completa satisfacción del cliente y un equipo de desarrollo motivado altamente motivado e innovador.
Lo Mismo con Diferente Maquillaje
Algunas organizaciones quieren los beneficios de Scrum, sin en realidad practicarlo:
- Sprints de tres meses: El cliente no ve un incremento del producto durante tres meses. Durante tres meses el cliente y el equipo de desarrollo acumulan supuestos sobre supuestos que generan un desagradable y descepcionante proceso de revisión del incremento. Peleas, gritos, búsqueda de culpables y sentimientos de “yo odio mi trabajo” porque tardamos tres meses para darnos cuenta que habían supuestos equivocados.
- El criterio de Done no es incluido en las estimaciones: El costo de implementar una User Story tiende a referirse: “Corre en mi máquina” o más deplorable aún: “Ya compila”. Esto genera desagradable sorpresas en los costos, y muy difícil de justificar y comunicar.
- El criterio de Done no incluye Quality Assurance ni Quality Control: Sin prácticas de desarrollo de Quality Assurance el equipo llega al “Code Complete” del User Story A y empiezan a desarrollar el User Story B, en algún momento Quality Control aparece y encuentra defectos en A, pero corregir esos defectos significan atrasos en la entrega de B que se está implementando. Resultado: Un producto con pésima calidad, el cliente no entiende porqué, Desarrollo y Quality Control echándose la culpa mutuamente.
- No hay equipo: De repente los desarrolladores son interrumpidos o “robados” para que soporten otros proyectos debido a sobre-compromisos irracionales. Esto causa un desenfoque carísimo pues ninguno de los proyectos se terminan entregando a tiempo.
- Working From Home: Los miembros del equipo nunca comparten tiempo estando físicamente cercanos unos a los otros en la oficina. [Nota: No tengo muchas cosas buenas que decir a favor de la política semanal fija del WFH para los miembros de equipos de cinco o más personas en donde la intensa colaboración para crear software es obligatoria para lograr alto rendimiento y armonía, en estos casos el WFH es mucho más destructivo que beneficioso: La desincronización es monstruosa y a tantos niveles que no se arregla con “Me mantengo online en el chat todo el día”, “Cuando me necesites me llamas”, “Mándame un correo”. Es el mismo motivo por el que los equipos de cualquier otra disciplina como en el deporte o teatro no hacen “Rehearsing From Home”,“Training From Home” o “Playing From Home”, ningún equipo se construye “From Home”. Y siendo sinceros, esta política se ha hecho famosa en Costa Rica en su mayor parte porque ciertos empleadores querían algo que ofrecer a sus empleados para que no renunciaran por mejores ofertas salariales].
- Standup Meetings convertidas en Status Meetings: Esto genera reuniones diarias más largas que 15 minutos, con contenido irrelevante para la mayoría de los asistentes y por lo tanto reuniones aburridas e inefectivas. Nadie está sincronizando nada: Sofía pensaba que Esteban estaba haciendo X así que con ese supuesto hace Y (en realidad Estaban está haciendo Z). Luis está bloqueado hace tres días en un problema que Mario pudo haberle ayudado a resolver en quince minutos.
Los anteriores son algunos de los intentos de poner una capa de spray sobre las mismas viejas prácticas que consideran que desarrollar software es lo mismo que hacer papas fritas.
El ScrumMaster que su organización necesita ha absorbido por completo el pensamiento Ágil y es un agente empoderado de cambio en su organización, no de promoción del status quo.
El ScrumMaster Nominal
En la oferta laboral de Costa Rica no es nada complicado encontrar personas que ya hayan cursado algunos de nuestros talleres o cursos de Scrum, los cuales hacemos regularmente. Esto sin duda es un cumplido para Prontitud: somos la fuerza a nivel regional detrás de la enseñanza y adopción de Scrum.
El valor de un entrenamiento inicial consiste en dar las bases teóricas para empezar a dar los pasos de la Ágilidad en el mundo real. De ahí que nuestro coaching después del curso sea una guía complementaria para lograr ese objetivo.
[anuncio] Asista a nuestros talleres de Certificación Scrum y considere nuestros servicios de coaching de Scrum en español en su organización.
Sin embargo, existe una relación herramienta-talento: un albañil no puede golpear efectiva y eficazmente sin un martillo, pero alguien que posea un martillo no es necesariamente un albañil.
Ninguna organización que busca llenar el puesto de ScrumMaster puede estar satisfecha con alguien que solo haya cursado un taller de Scrum.
Scrum es un excelente marco de trabajo para lograr beneficios que no se lograrían sin Scrum, pero sin un facilitador de Scrum sabio, este marco de trabajo nunca podrá ser implementado.
La sabiduría a la que me refiero sale a relucir cuando hay que decidir qué sabor de Ágil se ajusta mejor a las complejas circunstancias de la vida real. El ScrumMaster sabio sabrá qué principio o práctica en particular de XP, DSDM, Scrum o Kanban se ajusta a cierta circunstancia retadora.
En todo proyecto de software con resultados sorprendentes se puede observar dos fenómenos diferenciadores:
- Sobresalientes habilidades administrativas y persuasivas del líder.
- Usar como habilitadores vitales los elementos básicos de los procesos Ágiles.
El ScrumMaster nominal es aquél que lo único que tiene de Scrum es el título. Su organización no necesita ese tipo de ScrumMaster.
El ScrumMaster que su organización necesita es aquél que:
- Haya entendido que la naturaleza inherentemente incierta del proceso de caracterización del software requiere un pensamiento y un proceso adaptativo de concretización gradual en lugar de un proceso puramente predictivo.
- Es inteligente, su mayor arma es su capacidad de raciocinio, su cerebro.
A este respecto, nunca dejan de ser válidas las palabras de David Ogilvy:
“Si cada uno de nosotros contrata personas más pequeñas que uno, nos convertiremos en una empresa de enanos. Si contratamos personas más grandes, en cambio, seremos una empresa de gigantes. ”
[anuncio] ¿Es usted un ScrumMaster buscando una oportunidad de empleo? Contácteme.
