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

16

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.

haylem
fuente
¿Qué es la certificación? ¿Es ISO-9000?
Robert Harvey
1
Eres un poco ligero en los detalles; Si la certificación requiere un cierto nivel mínimo de artefactos para permanecer certificado, y la compañía ya ha asignado esos artefactos a su proceso de desarrollo de una manera que minimice el impacto, entonces no hay soluciones.
Robert Harvey
@Robert Harvey: un ISO-9001 sería un buen ejemplo. Cualquier cosa que necesite requisitos auditables y especificaciones de pruebas y trazabilidad para los propietarios de documentos y tareas.
haylem
@Robert Harvey: Sí, pero un mapeo solo necesita ser auditable. Por lo que puedo decir, la mayoría de los rastreadores de problemas / defectos / tareas / errores pueden ser parte de un seguimiento de auditoría, ya que registran la propiedad de una tarea a lo largo del tiempo. E incluso se puede vincular, en el caso del desarrollo de software, a un SCM para rastrear también los números de revisión. Además, puede usar su rastreador para identificar requisitos, especificaciones f e ID de prueba, y obtener sus matrices de trazabilidad desde allí.
haylem
@Robert Harvey: especialmente teniendo en cuenta el seguimiento de un ISO-9001 no es tan difícil de obtener y mantener, pero de alguna manera parece ser visto como algo que debe ser horriblemente redundante y detallado.
haylem

Respuestas:

12

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.

JoseK
fuente
Si bien otras respuestas fueron buenas, pensé que la suya fue la que más se esforzó por abordar la pregunta específica, no solo dando pistas generales sobre el uso ágil y tratando de descubrir por qué querríamos usarla. Buena respuesta. Gracias.
haylem
@haylem: me alegra que haya ayudado. En nuestro caso, nombramos a un miembro entusiasta del equipo, el Campeón Ágil para facilitar la transición. Nos hizo a todos conscientes de muchas de estas cosas. Tal vez podría ser voluntario para tal papel.
JoseK
8

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.

azheglov
fuente
Me gusta la idea de respetar el proceso existente. Sin embargo, no estoy seguro sobre el acortamiento gradual, puede proporcionar algo de dolor sin muchos beneficios. Iría a la compra de la alta gerencia y luego unas semanas acostumbraría a la gente al proceso ágil de los scrums diarios y las iteraciones de dos semanas.
Michael Durrant
6

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

fuente
+1: "Pregúntate por qué quieres usar Scrum. ¿Necesitas resolver un problema real?": Muy buen punto. Antes de introducir una nueva forma de trabajar, uno debe preguntarse qué intenta resolver. Desafortunadamente, la introducción de SCRUM (o cualquier otro método) para resolver problemas no existentes solo creará gastos generales y disminuirá la productividad en lugar de aumentarlo (hablo por experiencia directa).
Giorgio
3

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.

Nico Huysamen
fuente
1

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

KanbAnimation
fuente
+1 para la aceptación, especialmente teniendo en cuenta los comentarios en la pregunta que muestran la falta de aceptación.
Michael Durrant
@ KananAnimation: Creo que primero debes preguntarte si SCRUM es bueno para la empresa en la que estás tratando de presentarlo. (Desde mi experiencia directa) SCRUM no es mejor para todo tipo de proyectos y su presentación no siempre hace que una empresa sea más efectiva. Los ejecutivos convincentes (que podrían carecer de los conocimientos técnicos para comprender las consecuencias) de introducir SCRUM podrían dañar a largo plazo a la compañía si SCRUM no se ajustaba bien al tipo de proyectos que estaban haciendo.
Giorgio