Diferentes tipos de fluencia de alcance exigen diferentes soluciones. “Gestionar” el arrastre del alcance requiere evitar que ocurra en primer lugar cuando sea posible, y también guiar al equipo a través de él cuando ocurra.
Aquí hay algunos escenarios y respuestas.
- El Sprint roto. Si su tienda se toma en serio lo ágil, puede usar una metodología ágil para llamar a “falta” en respuesta al aumento de alcance durante un sprint. Agile trabaja en un ciclo de planificación / ejecución / evaluación. Cuando el alcance cambia durante la parte de ejecución del ciclo, el plan ya no es válido. La ejecución de acuerdo con un plan no válido es insostenible. En estas condiciones, el scrum master declara que el sprint está roto . Esto significa que el equipo necesita un nuevo plan. El sprint actual se abandona, los desarrolladores trabajan en deuda tecnológica u otros asuntos, el liderazgo del equipo vuelve a convocar reuniones de planificación de sprint, y el sprint comienza de nuevo una vez que hay un nuevo plan válido. Este procedimiento es formal y molesto, lo suficientemente molesto como para que tenga el potencial de enseñarle a la organización cuán malo es el arrastre de alcance y disminuirlo.
- JIRA o no sucedió. Otro tipo de cambio de alcance ocurre cuando un CEO, diseñador o PM bien intencionado asigna tareas a los desarrolladores con trabajo extra durante el sprint. El instinto natural de los desarrolladores es priorizar este trabajo por encima de sus tareas de sprint y sentirse bien con esa decisión, ya que el trabajo extra es una solicitud especial de una figura de autoridad. A veces, el líder ni siquiera sabe sobre este trabajo hasta que el equipo llega tarde a uno de sus entregables de sprint. Como líder o productor, combates esto de tres maneras. Primero, le dices al equipo que si alguien viene a ellos con trabajo extra, deben rechazar ese trabajo y enviarte a esa persona. En segundo lugar, hablas con esa persona en privado, explicando que eres responsable del horario y que lo que está haciendo socava tu capacidad de entrega; ¿podrían venir a ti en lugar de encargar directamente a los desarrolladores? En tercer lugar, implementa una regla JIRA o No sucedió : nadie trabaja en una tarea a menos que esa tarea esté documentada, estimada y priorizada en el sistema de gestión de tareas. JIRA es uno de esos sistemas; Pivotal Tracker es otro; incluso podrías estar usando una hoja de cálculo. Independientemente de lo que esté utilizando, asegúrese de que las tareas estén documentadas o sus desarrolladores perderán tiempo debido a que los ejecutivos los asignaron al azar y luego se preguntarán por qué reciben malas críticas.
- Estima y quema en horas, no en puntos de historia. Arrojaré un poco de gasolina en una tormenta de fuego ágil de larga duración: los puntos de historia no son tus amigos cuando manejas el alcance del alcance. Haga que su equipo haga una estimación en horas y haga que revisen esas estimaciones hacia arriba o hacia abajo todos los días durante el sprint. Esto no solo crea responsabilidad personal para la tasa de consumo, no solo enseña gradualmente a los desarrolladores a hacer mejores estimaciones basadas en el tiempo, sino que también expone a la organización, incluso al equipo ejecutivo, cómo se produce el aumento de alcance debido al trabajo descubierto . Esto conducirá a un amplio apoyo organizacional para otra técnica efectiva y peligrosa, la capacidad de reserva .
- Capacidad de reserva. La capacidad de reserva es una forma efectiva de gestionar el desplazamiento del alcance, pero no funciona como cree que lo hace, y puede ser contraproducente. Para implementar la capacidad de reserva, programe su equipo al 60% en lugar del 100% de su velocidad. Esto le permitirá mantener sus horarios incluso con un poco de alcance, ya sea debido a actores externos o debido al trabajo descubierto. La cantidad de reserva (también llamada contingencia) que necesita tomar para mantener su agenda es una métrica sólida de cuán disfuncional es su organización. El 60% es escandalosamente bajo, muy disfuncional, tan bajo y disfuncional que provocará una acción organizativa. Experimente con el número hasta que establezca una línea de base de trabajo, luego establezca una meta para todos (el equipo ejecutivo, los ingenieros, etc.) para mejorar esto continuamente hasta que pueda programar de manera confiable al 90% o más. Así es como la capacidad de reserva puede ser contraproducente: puede obtener un equipo ejecutivo o un equipo de desarrollo que reaccione con: “¡Eso es increíble! Por lo tanto, básicamente puedo volver a asignar tareas a los ingenieros o hacer malas estimaciones porque le has asignado tiempo, ¿no? ”No. Fallo. Eso no es lo que estamos haciendo. Lo que nos lleva al sacrificio .
- El sacrificio. Esta fue en realidad una pregunta de entrevista de trabajo cuando estaba aplicando para el trabajo de ingeniero principal en un gran estudio de juegos MMORPG. A veces tienes un ejecutivo o un primer ministro que no dejará de aleatorizar a tu equipo. Ella rechaza todos los métodos que he descrito anteriormente, con una lógica como: “Soy el jefe, sé sobre cosas que tú no, puedo interrumpir al equipo todo lo que quiero porque pago tus salarios”. En lugar de refutarlos. Con esta lógica, puedes sacrificar un ingeniero a tu señor no tan benevolente. Respondes con: “OK, entiendo. Permítame asignarle un ingeniero, que hará los experimentos que desee de inmediato. Luego, podemos trabajar con el equipo de administración de productos para obtener sus ideas en el producto una vez que se desarrollen ”. Para los desafortunados ingenieros que cumplen con su deber: los saludo. Lo estás haciendo por una buena causa. La otra parte tácita de The Sacrifice es que el ingeniero de mascotas de tu señor supremo no tiene permitido verificar nada en el principal , nunca: todo se hace en la rama aislada del señor supremo, y cuando debe fusionarse, lo hace el resto del equipo.
- Standups físicos. Cuando tienes una herramienta como JIRA o Pivotal Tracker, es tentador usar las funciones de scrum electrónico y tablero kanban de esos productos, posiblemente incluso eliminando por completo las paradas físicas, no lo hagas. Hay algo contraintuitivamente poderoso en hacer que cada desarrollador se pare frente a cualquier otro desarrollador y observador cada mañana para decir en voz alta, mientras actualiza o mueve físicamente una tarjeta de tareas: “Ayer pasé X horas en la tarea Y, pero descubrí Z horas de trabajo extra, así que mi nueva estimación es Q horas. Terminaré la tarea hoy “. O, más concretamente,” ayer no hice ningún progreso en la tarea X porque Sarah me dio una tarea de alta prioridad que no está en el sprint. Aquí hay una nueva tarjeta de sprint para ello. Terminé la tarea, después de pasar X horas en ella, y la estoy trasladando a HECHO ”. Ese es un momento público de WTF que incluso JIRA o It Didn’t Happen no pueden comprar.
- Burndowns públicos. Ponga su tabla de consumo en un tablero que todos en la oficina puedan ver. Cuando se agrega un nuevo trabajo a mitad del sprint, la tabla de burdeos se abulta y todos verán que sucedió. No solo lo verán, sino que hablarán sobre ello. Tener amigos en lugares altos también ayuda aquí. En una compañía, el Vicepresidente Sr. estaba muy del lado de la ingeniería, insistía en ver el gráfico de quemado cada semana, y golpearía al equipo de PM / Producción durante la revisión semanal si veía uno de esos abultamientos de alcance.
- Crujido. A veces se descubre trabajo, alguien realmente sopló una estimación y no hay más tiempo (por ejemplo, porque su producto está vinculado al lanzamiento de una nueva película, o al Black Friday, y esas fechas no se moverán). En esos casos, el último en la lista y como último recurso, quemas al equipo para hacer el trabajo. Esta no es una estrategia de gestión. Cada vez que tiene que aplastar al equipo, significa que usted, personalmente, como gerente, ha fallado, debe tomarlo tan en serio, eso personalmente. Necesitas tenerlo. Hacer el llamado a la crisis es parte de tu trabajo. Hazlo cuando debas.
- ¿Cuáles son algunas de las preguntas que un gerente de proyecto le haría a un desarrollador de software en una entrevista?
- Cómo ganar experiencia como desarrollador de software fuera de la universidad
- ¿Cómo es trabajar para Epic Systems en Madison, WI?
- ¿Cuál es su lista de tareas sugeridas para comenzar una comunidad para nerds tecnológicos?
- ¿Cuáles son las consideraciones clave antes de seleccionar una empresa de desarrollo de software?