¿Cómo presentar Agile a un equipo que utiliza métodos rígidos no Agile?

Considere una compañía que está orgullosamente certificada por alguna metodología no ágil, la usa como un punto de venta para sus clientes para demostrar responsabilidad.

¿Cómo se hace para introducir Kanban o Scrum progresivamente sin romper todo su sistema y aún así hacer que confíen en que todavía puede ser tan responsable / auditable ?

Sé que esto posiblemente esté relacionado con " ¿Cómo introduciría una metodología ágil como Scrum ", pero aquí me pregunto sobre las formas de eludir / evitar el hecho de que la compañía impone una cierta forma de administrar el SDLC bajo la falsa pretensión de que es La única forma de tener una pista de auditoría.

Creo que es un mito que los equipos de proyectos ágiles no documenten sus aplicaciones y este es el primer punto de resistencia que se obtiene en las empresas que están certificadas para tener la mejor documentación según sus estándares.

Trabajo en una empresa certificada ISO-9001, pero TAMBIÉN hacemos Scrums en una gran cantidad de nuestros proyectos. En nuestro caso, el cambio provino de los jefes de entrega del proyecto (es decir, personas bastante importantes) y es por eso que se adopta, en lugar de que un gerente o desarrollador del proyecto intente impulsar este cambio.

Una práctica útil que seguimos es documentar suficiente pero continuamente . Obviamente, esto significa que no seguimos todas las plantillas prescritas para el proyecto, pero hay una comprensión consciente y un acuerdo sobre qué secciones / documentos son necesarios frente a aquellos que son simplemente gastos generales sin sentido.

Entonces necesitaría socializar este punto de vista y obtener la aprobación del grupo de Calidad o la división de Estándares o como se llame.

El principio ágil es "suficiente" documentación. ¿Puede intentar empujarlo desde el Cliente para expresarle al equipo cuánto es suficiente? El gerente del proyecto podría hablar con el cliente y comprender cuáles son sus expectativas y necesidades organizativas y luego documentar la decisión y cumplir esas expectativas. Si es lo suficientemente bueno para ellos (es decir, los clientes que pagan), entonces puede ser lo que sigues.

Si piensan que Agile no se adapta a grandes proyectos, convencerlos de que puede hacerlo, por descomposición y esfuerzo paralelo.

En las grandes organizaciones, el control y la supervisión de los grandes programas se llevan a cabo mediante una Oficina de Monitoreo de Proyectos (PMO, por sus siglas en inglés) que lleva a cabo la planificación convencional de costos / contabilidad / gestión de recursos, etc. (la tabla de quemado SCRUM para uno). Necesitan saber cómo las técnicas como la integración continua los ayudan más temprano que tarde y, por lo tanto, es mejor para la productividad de todos eliminar los documentos generales.

Agile es un conjunto de habilidades que un equipo puede aprender que es en gran medida ortogonal a nuestras habilidades técnicas tradicionales. Pero si agrega esto a sus habilidades existentes, por supuesto, puede convertirse en un equipo más efectivo. Las paradas diarias (es decir, las reuniones de Scrum) no serán posibles de la noche a la mañana, ¿pero en la actualidad tendrías reuniones regulares de equipo (digamos quincenalmente)? Yo diría que empiece convirtiéndolos en siguiendo la agenda de preguntas de Scrum (no muy furtivamente;) y transmita al equipo más amplio por qué este enfoque puede funcionar y no significa documentación laxa / estándares pobres o cualquier otro mito.

Separaría a Scrum de Kanban primero.

Con Kanban, y aquí hay una fuente bastante buena sobre cómo hacerlo correctamente , el principio es que respetas el proceso de salida cuando comienzas. Kanban no es con lo que reemplaza el proceso existente, sino con lo que aplica. Planee, visualice y configure ciertas condiciones para una mejora gradual.

Scrum es fundamentalmente diferente en el sentido de que es algo que va a desplazar el proceso existente.

Un equipo que esté acostumbrado a ciclos de SDLC en cascada de 12 meses (o más) tendrá dificultades para realizar la transición a Scrum. El acortamiento gradual del ciclo a trenes de lanzamiento de 6 o 3 meses con un alcance más pequeño podría ser un paso intermedio útil.

Como cualquier cosa nueva que intentes presentar a una organización, enfrentarás una fuerte oposición. ¿Estás listo para ser criticado y ser el responsable si falla? Tienes que ser una persona fuerte. Ese es el precio a pagar cuando te expones.

• Pregúntate por qué quieres usar Scrum . ¿Necesitas resolver un problema real?
• Asegúrese de que USTED está comprometido con esto, porque nadie lo hará por usted. Serás el dueño de la cosa. Al menos hasta que traiga efectos positivos en la organización.
• Entrenar a ti mismo . Los libros e internet no son suficientes. Vaya primero a un curso, o aumentará dramáticamente su posibilidad de implementar Scrum incorrectamente. Lo que probablemente llevará a su equipo a peores resultados que antes
• Véndelo al equipo primero . Debes tener todo su apoyo, obviamente
• No propongas un cambio, propone una prueba . Y considéralo así. Scrum puede no ser adecuado para su organización (o para su equipo)
• Encuentre un patrocinador en la alta dirección

Esto es casi exactamente lo que sucedió en nuestra empresa. Seguimos métodos estrictos, no ágiles. Cuando se unió un nuevo Gerente técnico principal, que tenía cierta experiencia con SCRUM , pensó que sería bueno probarlo.

La forma en que lo hicimos fue tomar un pequeño grupo de desarrolladores (y analistas) para formar un equipo piloto SCRUM. Seguimos la estricta metodología SCRUM durante aproximadamente 4 meses, después de lo cual la compañía reflexionó sobre lo que hemos hecho, cómo lo hicimos, analizamos los datos (ya sabes, todo lo que los BA necesitan hacer).

Lo que encontraron fue que el piloto fue un gran éxito. Entonces formaron otro equipo que sigue a Kanban, y ellos también han sido un gran éxito. Creo que se habla de que el resto de los desarrolladores también forman equipos SCRUM / Kanban.

Creo que el piloto fue fundamental. Le da al lado estricto del negocio tiempo para evaluar y ver que funciona primero.

Soy un entrenador ágil y una de las claves para cambiar las iniciativas es la aceptación en todos los niveles. Esto incluye ejecutivos, equipos de desarrollo, gerentes, etc. Antes de anunciar un esfuerzo de cambio grande o pequeño, sugeriría que las personas se unan a usted primero. Hacer esto a través de una conversación en tercera persona es la forma más fácil para que las personas comiencen a buscar nuevas ideas. ¿Qué es una tercera persona? Un blog, video de youtube, presentación, ... etc. De esta manera, esas personas pueden comenzar a proponer sus propias ideas y con su influencia se unirán a una iniciativa de cambio.

Aquí hay dos videos astutos que he usado para despertar interés en todos los niveles de la cadena alimentaria.

Kanban: http://www.youtube.com/watch?v=0EIMxyFw9T8

Scrum: http://www.youtube.com/watch?v=Q5k7a9YEoUI