Introducción al desarrollo ágil después del inicio del proyecto tradicional

Hace aproximadamente un año y medio, ingresé a un lugar de trabajo que afirmaba hacer un desarrollo ágil. Lo que aprendí fue que este lugar ha adoptado varias prácticas ágiles (como stand-ups diarios, planificación de sprints y revisiones de sprint) pero ninguno de los principios (justo a tiempo / solo una mentalidad lo suficientemente buena, exponiendo el fracaso temprano, una comunicación rica).

Ahora se me ha encomendado la tarea de hacer que el equipo sea más ágil y me han asegurado que tengo una aceptación completa de los desarrolladores y el equipo de negocios. Como programa piloto, me dieron un proyecto que acaba de completar 15 meses de recopilación de requisitos, tiene un documento de Análisis y Diseño de 110 páginas (para ser considerado como "escrito en piedra"), y donde no tengo acceso al final usuarios (solo para el comité compuesto por los administradores de usuarios que en realidad no utilizarán el producto).

Comencé pequeño, dándoles una lista de los resultados esperados para los primeros 5 sprints (dejando los futuros sprints indefinidos), una lista de objetivos para el primer sprint, y diseccioné el documento de A&D para obtener suficientes historias de usuario para cumplir con los objetivos del primer sprint .

Desde entonces, se han preguntado por qué no tenemos todos los requisitos para todos los sprints, por qué no he comenzado a trabajar en cosas para el tercer sprint (que consideran más importante, pero se basa en los resultados del primero 2 sprints) y estoy presionando para obtener aún más documentación que todo mi equipo de TI considera ocupado o no relacionado con nosotros (como escribir el manual del usuario por adelantado, documentar todos los campos de datos de todos los sprints por adelantado, y más trabajo "por adelantado").

Esto ha sido bastante difícil para mí como nuevo gerente de proyecto, pero hay mejoras que he implementado de manera efectiva, como scrumban para la gestión de historias, programación de pares y hacer que el negocio nos dé pruebas de aceptación del cliente por adelantado (como parte de la documentación de requisitos) .

Entonces mis preguntas son:

1. ¿Qué puedo hacer para introducir más efectivamente el cambio en un negocio resistente?
2. ¿Existen otras prácticas que pueda introducir en el lado de TI para ayudar a mostrar al negocio los beneficios de Agile?
3. La carga de la documentación nos está estrangulando: el negocio todavía lo ve como una estrategia de gestión de riesgos en lugar de como un riesgo. ¿Qué podemos hacer para aliviar sus inquietudes y demandas de documentación (específicamente la cantidad de documentación y su necesidad por adelantado)?
4. Estamos en un edificio separado de nuestro negocio, a unas 3 cuadras de distancia y se rehúsan a que su gente en el proyecto co-habite b / c esa persona "no podrá trabajar en sus otros proyectos mientras están en nuestro edificio." Esperan que siempre vayamos allí y agrupemos nuestras preguntas para poder hacerlas todas a la vez y no perder el tiempo de esa persona con "interrupciones constantes". ¿Qué podemos hacer para obtener una comunicación más rica de ellos?

Cualquier consejo adicional también sería apreciado.

¡Gracias!

Me han asegurado que tengo una aceptación completa de los desarrolladores y el equipo de negocios [...] que no tengo acceso a los usuarios finales [...]

Una cosa que debe quedar bastante clara es la diferencia entre estar verbalmente seguro de que "tiene una aceptación", por un lado, y por otro lado, el compromiso real de quien patrocina su trabajo.

Mi mejor consejo para ti es dejar de lado la etiqueta "Agile". Prohibir la palabra de conversación en la medida de lo posible. En cambio, concéntrese en las siguientes cosas:

• Qué resultados se le pide que entregue (usted específicamente, no el equipo)
• Cuáles son los criterios de éxito para su misión (de nuevo, los suyos en lugar de los del equipo)
• Lo que significa que tiene a su disposición (incluyendo personas, acceso a personas, tiempo, información, presupuesto de capacitación, lo que sea)

"Hacer que el equipo sea más ágil" no es un objetivo factible. No es lo suficientemente específico, no es medible, no tiene condición final. Lo que necesita es algo específico: un objetivo expresado en términos de X por ciento menos defectos, o Y por ciento de sus fechas de entrega de características realmente cumplidas, por fecha Z.

Para alcanzar estos objetivos, es posible que deba introducir cambios. Ahora se aplican algunas reglas generales. Cada mejora es un cambio, pero no todos los cambios son una mejora. A menudo se dice que las personas se resisten al cambio, pero en realidad las personas se resisten a ser cambiadas y no saber si el cambio será una mejora.

Concéntrese en las prácticas que cree que serán fáciles de ganar, frutas bajas. Concéntrese en las prácticas que establecen un marco no solo para implementar el cambio, sino también para evaluar los efectos del cambio y asegurar a las personas que están resultando en una mejora en lugar de una regresión. Los "radiadores de información" son buenos, al igual que las retrospectivas.

Algunos de estos cambios pueden ser necesarios y percibidos como amenazantes, como tener más acceso a las personas que tienen información clave. No se comprometa con esto: "comprar" significa un proceso de negociación en el que realmente tiene la oportunidad de entregar lo que se le pide, no ser llevado como un cordero a la matanza política.

Trate de configurar las cosas para que sea difícil echarle la culpa a usted si las cosas no salen bien (y es probable que muchas cosas salgan mal). Tenga en cuenta que esto podría suceder, y esté preparado si sucede: conozca su estrategia de salida.

Con el fin de introducir una nueva cosa suavemente, es necesario asegurarse de que la gente no lo verán como una amenaza y permanente .

Muchos de nosotros estamos naturalmente conectados para evitar cualquier tipo de cosas nuevas. Es biologico. Las personas que generalmente buscan novedades nunca le causarán ningún problema. Debe asegurarse de que las personas más ansiosas no vean su sugerencia como una amenaza para su comodidad actual.

La forma ideal para que un equipo adopte una práctica o idea es asegurarse de que la idea provenga de ellos, y no de personas externas como la gerencia, o peor, algunos consultores al azar. Para que esto suceda, cree reuniones de lluvia de ideas con todo el equipo con un solo tema. El tema debería ser el problema. En la reunión, deberá presentar cuidadosamente las ideas y presentar argumentos y hechos.

No nos gusta tomar decisiones sobre cosas permanentes. Ya estamos ansiosos por el efecto de un cambio potencial. Ese comportamiento es bien conocido por las tiendas de mascotas. Comprar un perro es una decisión muy importante y probablemente cambiará radicalmente tu vida. Cuando esté en la tienda, el vendedor a menudo le propondrá llevarlo de regreso a casa y devolverlo si cambia de opinión. Como es de esperar, hay muy pocos retornos. La propuesta tiene un solo objetivo: reducir la ansiedad que impide que las personas tomen decisiones. Sugiera a su equipo de práctica que intente durante un período de tiempo fijo después de lo que evaluará su efecto.

Con respecto a su segunda pregunta, le sugiero que traiga una cosa a la vez.

Su problema de documentación merece su propia publicación aquí en P.SE y no veo ningún problema con el hecho de que esté en dos edificios diferentes si ambos están dispuestos a reunirse regularmente. Hay una situación en la que uno de los lados no quiere reunirse en absoluto;)

Ágil no es para todos, parece que a su negocio le gusta decir ágil porque es la mejor palabra de moda. En primer lugar, probablemente habría sido una buena idea impulsar un proyecto nuevo o proyectos de mantenimiento más pequeños para comenzar a hacer que su proceso se parezca más a las metodologías ágiles. Intentar rediseñar una metodología utilizando un proyecto que ya está en marcha es como tratar de cambiar un neumático en medio de una carretera de 8 carriles. Necesita una manera de demostrar que su negocio ágil puede funcionar, pero necesita un entorno en el que tenga la posibilidad de funcionar, pero basado en lo que ha dicho, es poco probable que ágil funcione bien con su cultura establecida.

Dependiendo de lo que quieran para la documentación, es posible que pueda mostrarles que esto se genera automáticamente a partir de una herramienta que está utilizando, o que es redundante y que el documento B tiene la información que se le solicitó mostrar. También debe ajustar sus planes de documentación, hacerles saber por qué están cambiando sus estimaciones y pedirles que reduzcan la cantidad de documentación solicitada o que dediquen recursos como un analista comercial para crear la documentación.

Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).

Ese es tu problema. No lo entienden. Alguien no puede pedirle que sea más ágil y que no esté dispuesto a acompañarlo. Tienen las expectativas equivocadas. Las cosas están rotas, por adelantado, incluso antes de comenzar. Corrige las expectativas o fracasarás. Es como si te pidiera que conduzcas 150 MPH y te doy una Chevette para que hagas eso.

Incorpore el tiempo / recurso / costo de la documentación que desean y permítales ver hasta qué punto empuja el cronograma.

Esto puede ayudar a mostrarles cuánto trabajo están presionando al equipo del proyecto y cómo esto podría reducirse si no lo estuvieran haciendo.