¿Formas efectivas de introducir ágil en el lugar de trabajo?

En su experiencia (anecdótica o de otro tipo), ¿cuáles son algunas formas efectivas de introducir Agile en una organización o empresa no Agile?

ACTUALIZADO: ¿Alguien puede hablar de casos en los que trató de presentar Agile pero fue "derribado"? Además, ¿ahora tiene una comprensión retrospectiva de por qué fue "derribado"?

ES DURO PERO NO IMPOSIBLE. A menos que vivas en el paraíso. Para pasos específicos que podría tomar, le recomiendo sinceramente que tome una copia de Fearless Change

• Primero obtenga el respaldo de la gerencia . Si no lo hace, nada más lo compensará ... Si el nivel superior es todo 'La fecha límite es ayer ...', 'Fines de semana de trabajo durante los próximos 3 meses', '¿Por qué escribes exámenes cuando deberías estar? codificación? ... podemos probar más tarde. El dodo simplemente no volará.
• Vea si la cultura de su organización es adecuada para ágil. Esto fue algo que me perdí ... Tomar prestada una línea del libro ... El proceso será más fácil y rápido si la cultura apoya y fomenta nuevas ideas, permite que las personas aprendan y hagan cosas nuevas, es lo suficientemente paciente como para apoyar las innovaciones con beneficios a largo plazo y no considera el incumplimiento como una sentencia de muerte
• La gente : Identifique a los innovadores: adoptadores tempranos: mayoría temprana: mayoría tardía: proporción de rezagados. Los primeros 3 son su público objetivo inicialmente ... debe estar alrededor del 30-40% ... lo que le da la masa crítica para comenzar. El problema es que Agile centra la atención en los elefantes en la sala ... las deficiencias y los problemas se vuelven fácilmente visibles ... si vives en un lugar que ha tenido una "Explosión de Bozo" (para citar el término de Guy Kawasaki) , el cambio sería realmente lento y doloroso ... en todo caso. Tenemos una tendencia a suponer que si una idea es buena, será aceptada. No es verdad. Muchas razones sociológicas levantan la cabeza.
• A continuación, no intentes muchas cosas a la vez. Tómatelo con calma ... tómalo con calma . El truco consiste en utilizar un enfoque de código de legado de refactorización. Encuentre pequeñas heridas aquí y allá y parchelas con un vendaje ágil. Asegúrese de que las personas entiendan la práctica y los beneficios y que los adopten con el tiempo. No todo se mantendrá, pero pronto mejorará en general. Qué tan pronto depende de una serie de variables, algunas de las cuales están fuera de su control.
• Es una gran inversión personal para que esto suceda . Vuelva a examinar si está dispuesto a comprometerse y pasar por los altibajos que trae. También es posible que tenga que entregar el testigo a otra persona o superior. Esté preparado para renunciar a la propiedad del cambio por un bien mayor. No caigas en el síndrome de 'Es mi bebé'.
• Agile es diferente para cada equipo, cada organización ... No todo lo que lees / propones funcionará ... deja que la aceptación te guíe hacia las cosas que funcionarán para tu escenario. Encuentre otras formas que compensen las prácticas que no arraigaron.

Espero que tenga sentido ... como habrás adivinado, he estado en esto por algún tiempo :)

Escuche al equipo, la gerencia, las partes interesadas y escuche las pistas. Es probable que sientan dolor en varias áreas que Agile aborda directamente.

Siga las sugerencias que pueden aliviar directamente esos dolores. "No puedes curar lo que no puedes sentir", por así decirlo.

Esto lleva mucho tiempo, pero generar confianza es de suma importancia. Con éxitos pasados ​​y teniendo la confianza tanto de su equipo como de su gerente, lo atenderán cuando llegue el momento de tomar decisiones.

Lo he visto con mis propios ojos, después de años de frustración al tratar de hacer que las personas cambien la forma en que entregamos el software. Y aunque ahora estoy teniendo éxitos, no estoy ni cerca de estar completo. Hay TONELADAS de áreas para mejorar, y actualmente estoy teniendo el mayor éxito al introducir pequeños cambios que abordan directamente algún tipo de dolor que sentimos.

Por último, solo diría que seas muy empático. Cometí el error de descartar la mayoría de las ideas antes de pensarlas realmente porque no lo leí en el "libro ágil XYZ". Escuchar a su equipo e intentar implementar algunas de sus sugerencias será de gran ayuda.

¡Buena suerte!

Saltando lo técnico, hemos descubierto que encontrar un grupo dentro de la organización que pueda comprar metodologías ágiles y proporcionar un 'banco de pruebas' fue crucial. Tuvimos muchas personas en nuestra empresa que no entendían una terminología ágil diferente, estaban confundidos por los términos y procesos, y había un temor general.

Mi grupo de investigación estaba muy interesado en tratar de hacer que Scrum funcionara (junto con varias otras metodologías de tipo Agile). Nuestro interés nos permitió formar un banco de pruebas dentro de la empresa para probar los diversos elementos. Enseñamos mucho primero: charlas en el pasillo con personas, presentaciones para ejecutivos de empresas, etc. No presionamos mucho, educamos. Luego pedimos permiso para probarlo con nuestro grupo.

Habrá muchas respuestas sobre cómo mostrar empíricamente cómo cosas como la programación de pares, el desarrollo basado en pruebas, Scrum, etc., pueden ahorrar tiempo, pero al final del día siento que la prueba debe provenir de su empresa. Encuentre un grupo que pueda usar como banco de pruebas y haga que realmente lo hagan. Nada aliviará mejor los temores que mostrarle a su grupo que lo hace posible.

Mételo en la garganta, pero sin que se den cuenta;)

He estado tratando lentamente de implementar principios ágiles (principalmente scrum) en mi lugar de trabajo durante los últimos 6 meses más o menos. La primera vez que introduje stand ups diarios, me costó un poco acostumbrarme a todos, pero está funcionando bastante bien. Como todos trabajamos en diferentes programas que forman parte de un solo sistema, es un poco difícil seguir scrum por definición. Mi siguiente paso es comenzar las reuniones de velocidad para seguir cada uno de nuestros lanzamientos. Ya comenzamos un ciclo de un mes, por lo que la duración del sprint no es un problema. También planeo seguir completamente los principios de scrum durante nuestro próximo gran proyecto. Soy uno de los dos desarrolladores del equipo para el proyecto, y él está a favor de la mejora continua. Espero que la gerencia vea los beneficios de lo que estoy tratando de lograr.

Creo que la clave es tomarlo con calma. Las personas que han estado en la misma posición durante años en general están en contra del cambio intrusivo, pero si puede escabullirse pieza por pieza, no deberían darse cuenta. Comience con las pequeñas reuniones frecuentes al principio también. Al mantenerlos cortos, la gerencia no debería verlo como una pérdida de tiempo en el reloj.

Desarrollo basado en pruebas. Demostrando cómo las pruebas unitarias pueden acelerar tu desarrollo. el tiempo al tiempo que hace que el código sea más estable es un gran primer paso para beber el ágil Kool-Aid.

Mejorarte a ti mismo primero. De Verdad. El ejemplo es la forma sólida de hablar sobre ágil. Además, como alguien ya dijo, evite las definiciones técnicas y simplemente use términos que los gerentes y ejecutivos puedan entender. Dos semanas en cambio Sprint; Planificación en su lugar Sprint Planning o Planning Game; Product Manager en lugar de Product Owner y así sucesivamente. Michele Sliger hizo una presentación increíble sobre Agile en la Waterfall Enterprise . Realmente hay que ver el video. También te pueden interesar otros videos sobre la adopción ágil .

Donde estoy trabajando, aprendo que Scrum es una buena manera de comenzar ágil porque la gerencia lo entiende rápido. Es simple y tiene un buen nombre. Más tarde, al hacer Retrospectivas, podría sugerir prácticas XP como mejoras y será bastante fácil que la gente acepte al menos probarlas.

Saludos cordiales

Lo introdujimos en nuestras tareas de 'Mantenimiento' (errores, cambios de bajo impacto, etc.) como un sprint de 2 semanas. Por lo tanto, los desarrolladores que estaban trabajando en proyectos a más largo plazo se quedaron como están, pero tuvimos un sprint rotativo de Mantenimiento. Por lo tanto, todos intentaron usar gráficos quemados y estimaciones de póker sin interrumpir los grandes proyectos.

Luego, a medida que finalizaba cada proyecto importante, comenzamos el siguiente usando sprints ágiles de 2 semanas. Todo este proceso tardó unos meses antes de que todos estuvieran en sprints, pero significó que hubo menos interrupciones y todos pudieron 'facilitar' el proceso

Dentro del equipo de desarrollo, la presentación de Agile es mucho más algo sobre lo que tiene cierto nivel de control.

Sin embargo, veo que el problema principal es el requisito que Agile tiene para solicitar comentarios continuos de su "cliente" o representante del cliente.

Por lo tanto, realmente necesita enfocarse en el lado educativo de las personas que están fuera de su equipo de desarrollo directo, ya que es probable que de alguna manera necesiten cambiar la forma en que trabajan (es decir, mucho más contacto con el equipo de desarrollo).

La mejor manera que diría es enfocarse en los beneficios inherentes de asumir un proceso ágil y transmitirlos claramente a su cliente. Por supuesto, si tiene un área de ventas / cuentas en su empresa, lo mismo se aplica allí.

Paso 1: asegúrese de que su proyecto tenga una acumulación de trabajo pesado y asegúrese de que tenga prioridad

Paso 2: introduzca las prácticas SCRUM (iteraciones manejables, standups diarios, scrum-master, propietario del producto, gráficos de burndown)

Paso 3: cada iteración presenta los resultados del equipo con el burndown

luego ...
implemente TDD / BDD, programe pares, revise los códigos (todo muy suavemente), y si tiene un equipo lo suficientemente bueno, ubique a todos en el mismo lugar (una sala de equipo si es posible).

Sobre todo, comprenda que habrá resistencia (SERÁ), así que prepárese para manejar eso.

Otra cosa para recordar es que si usted es parte de una organización (grande o pequeña) que en su conjunto no seguirá estas mejores prácticas, entonces puede llevar un tiempo (si es que lo hace) sentir que está progresando.

Las personas siempre son resistentes al cambio, y pasar al scrum es bastante importante. La motivación y la dirección son clave.

El primer paso es motivar a las personas para que le den una oportunidad a scrum. Descubrí que Google Tech Talk de Ken Schwaber ha sido muy útil para hacer que las personas reconozcan los beneficios del scrum al tiempo que proporciona una buena introducción. Comience con las personas que cree que serán receptivas al cambio, ya sean desarrolladores o gerentes, para que pueda generar un impulso. Conseguir que los gerentes estén de su lado será una necesidad en algún momento, pero la forma en que maneje eso depende de su entorno.

Después de eso, todos deben ser entrenados, ya sea para leer un libro o para tener una serie de conferencias. A menos que las personas sepan cómo funciona scrum, no puede comenzar a intentar implementar el proceso.

Una vez que las personas están motivadas y tienen una idea de lo que deben hacer, debe tener su primera reunión de planificación y configurar las partes necesarias de scrum (scrummaster, reuniones diarias, etc.).

Esperaría que la primera reunión de planificación no transcurra sin problemas y que sea una experiencia de aprendizaje para todos. Además, los primeros sprints serán muy difíciles, y probablemente tarde. La parte clave ahora es la disciplina y la persistencia. No permita que las reuniones diarias se prolonguen demasiado, mantenga las reuniones de planificación enfocadas y asegúrese de que todos desempeñen sus funciones correctamente.

Creo que las personas que son más resistentes son las personas que han estado desarrollando software durante mucho tiempo, o las personas que sienten que al pasar al scrum, están admitiendo que estaban haciendo algo mal antes. Es un obstáculo difícil de superar, pero creo que al mostrarles los beneficios, puede convencerlos lentamente. Solo lleva tiempo. En mi experiencia, los gerentes de producto son realmente resistentes porque los obliga a ser más claros acerca de sus requisitos y lo que quieren. Pero una vez que ven cómo el proceso ágil los beneficia y les hace la vida más fácil, se embarcan bastante rápido.

¡Buena suerte!

• Demuestre éxito: vea la respuesta de Mark
• Prestar especial atención a los principios / técnicas que causarían el mayor impacto en la empresa.
• Recuerde que se trata de principios ágiles y no de una lista de verificación del proceso

Antes de pensar en introducir un desarrollo ágil, primero explore cuál es el más adecuado para su organización / proyecto. Si, por ejemplo, está mirando scrum, considere si lo usaría estrictamente o si una forma más suelta de scrum, o incluso cualquier otro método podría encajar mejor. Mi respuesta está en scrum como su método ágil.

Scrum es ideal para proyectos que requieren innovación, donde se sabe poco y donde se necesita experimentación. No es la mejor opción para hacer cosas como mantener productos existentes o manejar trabajos de mantenimiento recurrentes. Afortunadamente, scrum es un marco suelto y puedes usarlo de la mejor manera posible.

Para el trabajo de mantenimiento, Kanban puede ser mejor para usted o puede probar solo algunos elementos de scrum para administrar el sprint y hacer cosas como las paradas diarias. Yo llamo a esto "scrum-but", "sí, hacemos scrum en nuestra empresa pero ...". Eso está bien, no te sientas mal por eso.

Para introducir scrum propiamente en su organización, necesita la participación del propietario del producto y el interesado. Si eres una empresa pequeña, ese tipo podría ser una persona, el jefe, y en una más grande un gerente de producto y el jefe / jefe del departamento. Sugeriría dos rutas para introducir scrum:

1) puede comenzar a usar scrum en una forma ligeramente más flexible para administrar las colas de trabajo existentes de inmediato. Pero mira también a Kanban.

2) comience a usar scrum de forma más estricta en algún proyecto nuevo que requerirá innovación, retroalimentación temprana y donde se desconoce mucho. Puede sugerirle al jefe / propietario del producto que scrum sería ideal para este nuevo proyecto.

¡Pero recuerda! No se trata solo de código, el propietario del producto tiene una parte crucial y debe comprender y cumplir su función. Eso significa, por ejemplo, no escribir todas las especificaciones por adelantado, sino comenzar con el mínimo, iterar rápidamente, obtener retroalimentación, aprender y alimentar eso, etc. Intente trabajar con un gerente de producto que esté tan interesado en introducir scrum como usted, pero desde el lado del propietario del producto, e idealmente él / ella debería ser lo suficientemente fuerte como para defenderse de las solicitudes de administración y proteger el sprint.

Se necesitará un esfuerzo conjunto del desarrollo y la gestión de productos para introducir scrum.

En un proyecto tan nuevo, intente que el nuevo equipo se traslade a una habitación separada y use notas post-it para visualizar el trabajo en los diversos estados, como el trabajo atrasado, en progreso, etc. No se atasque en herramientas electrónicas en esta etapa. , mantenga las cosas lo más simple posible. Cuando comiences, no te hagas el tonto planificando póker con cartas, una vez que tu equipo esté listo, probablemente no las uses solo para decir los números.

En mi experiencia, es más fácil introducir scrum en una forma pura primero y luego facilitarlo para obtener más colas de trabajo de tipo de mantenimiento. Es más difícil al revés.

Mi comentario final es tener cuidado al pensar que scrum es una panacea de desarrollo, no lo es. Scrum es un marco útil y simple para la innovación de productos, pero explore otros métodos combinados según lo requiera su empresa y no se sienta mal por ello.

Hace algunos años, fui consultor en una empresa muy grande (casi 20,000 empleados) que estaba ejecutando muchos proyectos de software empresarial de gran tamaño. Estaba en uno de ellos. Una muy crítica.

Enfrentamos muchos problemas y la presión se ejerció fuertemente sobre nosotros, el equipo de desarrollo. Los problemas eran comunes a la industria del software, pero la administración tenía una experiencia más orientada a la infraestructura y muy poca experiencia orientada al software. Entonces todo se centró en nosotros. Pensé que sería una gran idea contarle a la gerencia sobre Scrum.

Me enfrenté a una fuerte renuencia, por lo que abandoné la idea por un tiempo. Pero los problemas continuaron aumentando, así que con el patrocinador del líder del equipo, finalmente decidimos hacer Scrum de todos modos, por nuestra cuenta.

Cualquiera, incluido yo, tenía alguna experiencia con Scrum. Entonces descubrimos el marco haciendo ...

Hoy, Scrum se generaliza a toda la empresa a través de un programa administrado por un entrenador certificado. No sé si nuestra iniciativa fue el detonante. Dicho esto, sé que fue una verdadera revolución en una compañía bastante rígida.

Creo que para introducir algo en una empresa como esa, debes respetar los siguientes principios:

• Tiene que cambiar es necesario . Si no hay una razón convincente para que el cambio deba realizarse, no hay ninguna razón por la cual los equipos de gestión estén en su lugar para asumir riesgos.

• Debemos centrarnos en los problemas de gestión y no mencionar los problemas de los desarrolladores, a menos que sean parte de las preocupaciones de gestión. En otras palabras, debe encontrar una solución para ellos, no para usted. Ponte en el lugar de la gerencia. ¿Cuáles son sus preocupaciones?

• No debe proponer cambiar toda la organización de una vez . Debe proponer un proyecto piloto del que asumiría la responsabilidad. Te aconsejo que des objetivos realistas, como el aumento significativo de la visibilidad de lo que está sucediendo en el proyecto. Es, en mi humilde opinión, la principal contribución de Scrum a la gestión de software. Permite que el sentido común humano opere y así avance.

• Finalmente, es imperativo asegurar que las personas con experiencia tengan el control de esta introducción. No solo lea un libro o dos. Tienes que ir a entrenar y yo diría que es bastante necesario usar un entrenador experimentado. Obviamente, se puede hacer sin él, pero será doloroso :)

Si sigues los principios y vienes con hechos, funcionará. Acerca de los hechos, encontrará muchos en el libro Software en 30 días: cómo los gerentes ágiles superan las probabilidades, deleitan a sus clientes y dejan a los competidores en el polvo . Es el último libro de los creadores de Scrum, Ken Schwaber y Jeff Sutherland .

En una publicación de blog de Ken sobre el libro puedes leer:

Jeff Sutherland y yo lo hemos hecho. Escribimos un libro juntos, nuestra primera escritura conjunta desde la publicación inicial de Scrum en 1995. ¿Qué nos motivó? La pregunta que frecuentemente nos hacen:

¿Cómo vendemos Scrum a nuestra gerencia?

Siempre me ha intrigado esta pregunta. ¿Por qué tendría que vender más previsibilidad, productividad, calidad, valor, control de riesgos, clientes satisfechos, empleados comprometidos y menos desperdicio a cualquiera en la administración? Sin embargo, hablé con Jeff y pensamos que donde había humo, debía haber fuego.

Pasamos la última mitad de 2011 escribiendo el libro. Cualquier gerente, de arriba a abajo, puede leer y leer fácilmente este libro.

[...]

Lo vemos todo el tiempo. (divulgación completa: estoy desarrollando una aplicación de gestión de proyectos). El problema es que las metodologías ágiles introducen una tensión inherente en las organizaciones administradas tradicionalmente. Por lo general, las administraciones superiores quieren poder planificar con anticipación. Quieren planes de 3 años; quieren proyectos adecuadamente estimados; quieren poder presupuestar la contratación de nuevas personas; quieren poder comprometerse con hitos significativos cuando se trata de socios / clientes.

Pero luego, el departamento de I + D decide que será ágil. Ya no se trata de planificar por adelantado durante dos meses antes de escribir el código. Los sprints serán cortos y más allá de los sprints obtienes estimaciones de muy baja resolución de las cosas que están en el backlog / roadmap. R&D se da cuenta de que los requisitos cambian con demasiada frecuencia para que la cascada clásica sea efectiva, pero los gerentes de producto desean una visión clara, pensada y bien presupuestada de cómo se verá el producto en 12 meses.

El problema, entonces, es conciliar los dos. Como dije, vemos que esto sucede todo el tiempo con nuestros clientes. Por lo tanto, nuestra solución es unificar las herramientas utilizadas para hacer sprints y planificación a largo plazo. Bien, ahora aquí viene la parte del tapón descarado, así que siéntete libre de tomarlo con un grano de sal. Una de nuestras características únicas es que utilizamos una interfaz de usuario con zoom para administrar las tareas. Lo que significa que es muy fácil profundizar en alguna historia / tarea de usuario y desarrollarla. (Puedes ver cómo se ve aquí ). En realidad, no hay ningún concepto de "proyecto" en nuestro sistema. Todas las tareas contienen otras tareas, vinculadas a otras tareas (un fractal, en realidad). Esto crea un bonito desenfoque entre historias de usuarios, tareas, proyectos, epopeyas, etc.

En la práctica, lo que hacen muchos de nuestros usuarios que practican metodologías ágiles es crear un plan telescópico que combine la hoja de ruta a largo plazo (o la cartera de pedidos) con la gestión de los sprints (o iteraciones) a corto plazo. Los gerentes aún pueden ver una buena hoja de ruta estimada de las principales características que esperan ser agregadas, y los desarrolladores simplemente se acercan más y se ocupan de las tareas de trabajo reales. Una ventaja que tiene es que reduce la cantidad de "regateo" que tiene lugar cuando los gerentes revisan el plan de trabajo. En lugar de que el equipo de desarrollo proporcione solo estimaciones muy aproximadas (es decir, "¡4-6 semanas!"), Tienen la oportunidad de ampliar cada historia de usuario en cuestión y dividirla en fragmentos más pequeños. Cuando haces eso, de repente hay menos espacio para regatear. Pasas 10 minutos desglosando una historia de usuario de 5 semanas en fragmentos que tienen un tamaño de aproximadamente 1 día, y de repente el argumento no es "no, puedes hacerlo más rápido. No, no podemos. Sí, puedes". pero "esto es lo que implica este esfuerzo, incluido todo el trabajo oculto que la estimación inicial no consideró. ¿Qué sugiere que eliminemos? ¿Garantía de calidad? ¿Pruebas? ¿Entrenando al nuevo tipo? ¿Configurando el entorno de construcción?".

Este enfoque funciona siempre que utilice una herramienta que le permita cambiar de planes tan rápido como los redacte inicialmente. Cuál es la verdadera razón por la que la gente en estos días detesta la cascada La mayoría de los sistemas hacen que sea extremadamente difícil rehacer por completo los planes existentes y las personas se niegan muy racionalmente a perder el tiempo en esta actividad.

Bien, siento que esto se está convirtiendo en un argumento de venta, así que me detendré ahora. :)