Escapada de la isla Waterfall (parte 1 de 2)

• July 7, 2015• 5 min•
waterfall_island¡Socorro, Socorro! Estamos atrapados en la isla Waterfall! Favor de envien ayuda de inmediato! “Si recibiera esta alerta, ¿cómo podría responder a los ciudadanos de la isla Waterfall?
En el  Scrum Gathering in Phoenix, Peter Stevens de Suiza, ofreció esta estimulante lista de preguntas a considerar cuando se piensa en cómo ayudar a la gente moverse de la vieja manera de hacer las cosas (Isla Waterfall) a un enfoque más ágil.
  1. ¿Quieres que yo esté aquí? Muchas veces las personas dicen que quieren empezar a hacer Scrum o Agile, pero en realidad no están interesadas ​​en hacer cambios significativos en su comportamiento o en la organización. O están dispuestos a que otras personas cambien con tal de que su mundo no cambie. Otro escollo a tener en cuenta es cuando el equipo declara su experiencia en un proceso ágil, pero en realidad tiene (sub)optimizado su proceso ágil en torno a sus particulares disfunciones organizativas.
  2. ¿Qué está tratando de lograr? En la carrera por conseguir que un nuevo proyecto arranque, esta pregunta a menudo se pasa por alto. Más importante aún, cómo Scrum y Agile apoyan el objetivo de negocio de la organización es la esperanza de realizar. También me gustaría añadir que si los stakeholders no pueden describir su visión para una mejor organización, está pobremente articulado o está mal alineado con lo que los equipos tienen en mente para una mejor organización, entonces todo lo que se implementa con respecto a Scrum y Agile será superficial y temporal .
  3. ¿Cuál es su mayor obstáculo? Algo está pasando (o no pasando) en la organización que llevó a la empresa a iniciar este proceso de investigación sobre la adopción de un proceso ágil. Recomiendo ​​preguntar los Stakeholders como este impedimento afecta a su crecimiento futuro, las metas de ingresos, la innovación de productos, calidad y\o la satisfacción del cliente. Si el impedimento no se mueve uno de esos cinco factores, no es el verdadero impedimento.
  4. ¿Cuál fue su mejor proyecto? Pregunte a personas acerca de sus experiencias sobre ser miembro de un proyecto exitoso en la organización. Investigue cuáles fueron los factores que permitieron que el proyecto tuviera éxito. ¿Fue el trabajo? ¿La gente? ¿Participación de la dirección? ¿Participación de los clientes? ¿Algo relacionado con la tecnología? Ponga estos artículos en una lista y asegúrese de tener estos elementos antes de comenzar. Consulte la lista cuando la iniciativa de cambio tome forma para confirmar que estos factores siguen presentes.
  5. ¿Qué ha funcionado en el pasado? La gran mayoría de organizaciones saben cómo tener éxito, de otra manera irían a la quiebra. En mi opinión, uno de los factores que conducen a que muchas empresas estén interesadas en Scrum y Agile es que han olvidado como cumplir, es decir, conseguir una victoria. Con esta pregunta, el trabajo consiste en descubrir lo que el negocio ya sabe como hacer bien y luego encontrar maneras de aprovechar esa experiencia en la nueva forma de trabajar juntos.
  6. ¿Quién quiere que este sea el mejor proyecto? Esta pregunta puede parecer completamente obvia, pero tome un momento para preguntar a los participantes si quieren que este proyecto sea el mejor proyecto de todos los tiempos. Esta simple pregunta tiene múltiples objetivos. Uno, establece el nivel de éxito muy alto. Nadie quiere entregar algo mediocre. Dos, la cuestión alienta a los participantes a comprometerse pronto para ser participantes activos en el cambio de cultura. Tres, esta pregunta desentierra los obstáculos que impidan que este proyecto sea el mejor proyecto de todos los tiempos. Si lo que los participantes dicen son un montón de obstáculos, recomiendo jugar Fearless Journey para ayudar a los participantes a ver que el cambio es posible y real.
  7. ¿Quién es el propietario del producto? Sin un Product Owner, Scrum no funcionará. No empiece Scrum a menos que tenga un Product Owner que esté facultado, comprometido y disponible. En casi todos los casos el Product Owner debe venir de la empresa. La verdad es que no me gustan los Product Owners técnicos. Si la empresa no ve el beneficio de la estrecha colaboración con el equipo técnico, por ejemplo, no se asigna un Product Owner a tiempo completo para el equipo, no haga Scrum.
  8. ¿Dónde duele? ¿Qué es realmente tan malo en la Isla Waterfall? Una vez más, otra pregunta evidente, pero el objetivo es reunir información de cada parte de la organización acerca de lo que duele. Permanezca empático durante la captura de lo que la gente le dice y asegúrese de señalar cualquier dolor al que ya se hayan acostumbrado. Pídales que clasifiquen estos dolores de extremo a moderado.
  9. ¿Cuál es la definición de hecho? Si la organización es nueva en Scrum y Agile, tome un momento para crear la “definición de realizado”. Si los participantes tienen experiencia, revise su actual “definición de realizado” y actualízelo. Le garantizo que está caducado. “Definición de realizado” es un concepto importante y vital para la restauración de la confianza entre el equipo y el negocio. Como más y más equipos trabajan en la misma base del producto y el código, la “definición de realizado” tendrá que converger para que todos tengan las mismas expectativas sobre lo que define a un producto de calidad.