¿Scrum o Kanban son realmente útiles para los equipos SRE?

Las prácticas ágiles como scrum y kanban se diseñaron principalmente para el desarrollo de software.

El trabajo interrumpido y no planificado es un componente importante de lo que hacen la mayoría de los equipos SRE ( Ingeniería de confiabilidad del sitio ) o DevOps. Si bien siempre es útil usar un sistema de seguimiento como Jira para administrar el trabajo, ¿realmente funcionan sprint o kanban para los equipos SRE?

Las restricciones que veo son:

• El trabajo es de naturaleza muy dinámica, con prioridades que cambian a diario. Debido a esto, la duración del sprint de dos semanas parece muy agresiva y agrega una sobrecarga innecesaria.
• La gente que está de guardia agrega otra dimensión al problema. A veces, más de un miembro del equipo puede involucrarse en tareas de guardia / post mortem.
• El equipo no tiene un solo "producto" y, por lo tanto, no se rinde a un proceso de planificación común
• Las reuniones de pie diarias pueden no tener mucho sentido debido a la falta de superposición entre tareas
• El equipo podría estar trabajando en tareas relacionadas con más de un equipo asociado y, por lo tanto, abarcar múltiples proyectos de Jira. Dado que un tablero de sprint o kanban permite solo un proyecto de Jira, es posible que no pueda encajar en todo el trabajo.

Por lo que escuché de muchos SRE con los que he hablado, la planificación de sprint no les ha funcionado en absoluto. Me gustaría escuchar de la comunidad aquí cuál es su experiencia con Sprint y Kanban.

También hice esta pregunta en scrum.org:

¿Pueden los equipos SRE utilizar eficazmente scrum?

No utilizamos Agile para el grupo DevOps nosotros mismos, pero sí nos integramos con los equipos Scrum normales. Cuando el equipo de DevOps necesita algo, como la optimización del servidor de compilación, el equipo relacionado coloca un PBI en su cartera de pedidos con una etiqueta 'DevOps'. Nuestro líder tiene un tablero personalizado en Jira con todos los problemas etiquetados como 'DevOps'. Trabajan con el Scrum Master para obtener prioridad y luego uno de los ingenieros de DevOps tiene la tarea de ser un miembro ad-hoc de ese equipo Scrum durante toda la vida de ese problema. Esto nos ayuda a priorizar el trabajo en función de las prioridades de nuestros "clientes", vincula nuestro esfuerzo al sprint y nos permite obtener "crédito" por el trabajo que estamos haciendo.

Antes de esto, utilizamos Kanban en Jira solo para una lista de tareas pendientes. Desafortunadamente, a veces tendríamos que dejar de trabajar en algo en lo que habíamos planeado trabajar porque uno de los equipos necesitaba algo. Ahora, a menos que sea una emergencia, básicamente solicitan recursos de DevOps (personas / tiempo) a través de su cartera de pedidos y el Scrum Master comunicando esa necesidad a nuestro líder.

Ágil funciona muy bien para este tipo de entorno caótico. Sin embargo, por las razones que destacó, el libro de texto puro Scrum puede no ser un gran ajuste. Como Scrum Master que hace una buena cantidad de DevOps, he usado tableros Kanban en Jira para rastrear el trabajo.

Ventajas de Kanban

• Visualización del trabajo que realiza el equipo.
• Identifica cuellos de botella para el equipo.
• Ayuda a mantener al equipo enfocado en avanzar el trabajo.
• Permite que el trabajo se agregue en cualquier momento.
• Da visibilidad al trabajo que se está realizando para otros equipos que dependen de las SRE.
• Puede ser genérico para cubrir múltiples tipos de trabajos.

Si bien un stand up tradicional puede no ser beneficioso, considere modificarlo. Una buena reunión de pie resalta los bloqueadores que un miembro del equipo puede enfrentar y que otro miembro del equipo sabe cómo resolver.

OMI: Sí, los equipos SRE pueden usar eficazmente Scrum. Nunca he escuchado o leído que los miembros del equipo solo pueden trabajar en elementos de trabajo de sprint, por lo que es un error pensar que debes dar cuenta de todo tu tiempo y esfuerzo en el alcance de un sprint; Además, creo que hay una idea errónea de que todo su trabajo es aplicable a los sprints. Por lo tanto, de manera convergente, debe administrar algo de trabajo con Scrum y algo fuera de él.

Scrum, en su esencia, es un marco (con artefactos y eventos) que es flexible y se usa para la mejora continua sobre la naturaleza del trabajo aceptado por el equipo (o aplicable a dicho trabajo).

Lo que debe hacer es lograr un equilibrio entre el tiempo y el esfuerzo que puede proporcionar para el trabajo de sprint planificado y aceptado que usted y su equipo pueden cumplir y el tiempo y el esfuerzo para abordar el trabajo no planificado fuera del sprint.

Hay una medida de severidad y prioridad para todos los elementos de trabajo. Si está considerando Scrum, debe aceptar el trabajo hasta una gravedad particular. También debe considerar el trabajo que puede reducir la gravedad del trabajo futuro (si es posible). También te recomendaría que comiences tus sprints con aproximadamente la mitad de la capacidad (lo cual sería difícil de determinar ya que relacionar el tiempo y el esfuerzo de una manera de capacidad al principio es): ve ligero. El objetivo de su equipo siempre debe ser entregar lo que su equipo acepta, así que sea exigente y no se extienda demasiado.

Creo que la naturaleza de su trabajo es realmente comparable al trabajo de corrección de errores de producción para los equipos de desarrollo. Por lo tanto, es posible que desee consultar a los equipos de mantenimiento de producción sobre su adopción y éxito de Scrum, y no necesariamente limitarse a la experiencia de los ingenieros de DevOps en la gestión de programas y proyectos.