Como scrum master, ¿cómo hago para que todos se tomen en serio los plazos?

Los miembros de su equipo no están comprometidos porque no disfrutan el trabajo. Su primera respuesta sería sentarse individualmente y en privado con los miembros del equipo de bajo rendimiento y preguntarles cómo se sienten acerca del trabajo que están haciendo. Una vez que haya identificado los problemas, puede tomar medidas más específicas.

¿Es un problema de herramientas? Ayúdelos a obtener las herramientas que necesitan (por ejemplo, tener que usar Visual Studio Express simplemente porque la empresa es demasiado barata/frugal para pagar una versión Pro es desmoralizador).

¿Es cosa del cansancio? ¿Están cansados ​​de suicidarse para cumplir con los plazos en los que no tenían voz? Trate de equilibrar las presiones de la fecha límite con el tiempo libre. Más horas a menudo no equivalen a más productividad.

¿La gerencia de la empresa está loca y los desarrolladores tienen dificultades para aceptar su loca visión? ("Loco" es una palabra subjetiva: ¿el equipo está de acuerdo con la dirección y la visión de la gerencia?) Ofrezca ayudarlos a protegerse de la locura y dejar que se concentren en su trabajo.

¿El trabajo es poco interesante? Ayúdalos a encontrar su propio propósito en el trabajo que están haciendo.

¿Son simplemente de bajo rendimiento? Es posible que deba eliminarlos del equipo y reemplazarlos con alguien más competente y adecuado para las tareas.

Tu problema está en la primera oración:

Soy scrum master y también project manager

Tienes 2 roles que están en desacuerdo entre sí.

Un Scrum master tiene dos competencias:

• Eliminar obstáculos
• Asegúrese de que se siga el proceso acordado y asesore donde no se cumpla.

Tenga en cuenta que no digo nada sobre el cumplimiento de los plazos, no hay plazos en Scrum.

Trabaja en intervalos establecidos (sprints/scrums/timeboxes, etc.), la cantidad de trabajo que puede realizar se basa en métricas (velocidad en Scrum) y si algo no se puede terminar en el intervalo actual, continúa en el siguiente (pero lo ideal es mantener las historias lo suficientemente pequeñas como para que no suceda).

Esto no es gestión de proyectos, que generalmente se basa en fechas fijas. La razón de esto es que se ha demostrado que seleccionar una fecha arbitraria no funciona y Scrum (y otros procesos ágiles) están diseñados para funcionar sin esto.

Si el equipo no está "entregando", debe mirar sus métricas. ¿Mantienen una velocidad? Si no, ¿por qué (cosas que resultan más difíciles/deuda técnica/historias poco claras, etc.)? Si hay problemas con el funcionamiento del equipo, reúnanse y resuélvanlo con el equipo (autogestión, ¿recuerdas?).

Como maestro de Scrum, debe saber acerca de cualquier impedimento, ¿o es porque los está presionando para que tengan fechas y, como resultado, no se lo dicen? Al final del Standup, debe saber de cualquier problema y estar al tanto. Piense en estrategias que pueda sugerir para que las cosas funcionen mejor.

También debe mirar específicamente las historias, el tamaño y las dependencias. Usa lo siguiente en ellos:

• independiente _
• negociable _
• valioso _
• E stimable
• pequeño _
• estable _

Lo que encuentro que funciona es hacer el trabajo más grande al final de la historia, trabajar con los equipos en el momento de la creación para hacer que las historias tengan tamaños pequeños similares, extraer dependencias y minimizar el trabajo NO HECHO.

Una vez que haga esto, puede comenzar a realizar un seguimiento de las métricas en el tiempo de entrega/tiempo promedio de la historia, etc., y esto debería permitirle abandonar la estimación del 10% para el equipo y usar las prioridades para elaborar planes a largo plazo para su proyecto.

A medida que monitorea los tiempos de las historias, puede negociar con PO/negocios, etc. sobre historias/prioridades para garantizar que las historias más valiosas se entreguen en el tiempo planificado y darles un marco de tiempo realista para la entrega.

Scrum (u otros procesos ágiles) tiene que ver con la mentalidad. Es deliberadamente simple de hacer, pero requiere disciplina e interés para trabajar. Nada se estrella y se quema como un proceso Agile en el que las personas solo están hablando de la boca para afuera, ya que puede parecer que las cosas están progresando cuando no es así, hasta que es demasiado tarde para detener el barco. Si realmente no compran, puede ser mejor volver a un enfoque en el que estés rastreando el inicio/finalización de las tareas, para que puedas presionarlos cuando no cumplan con la fecha límite de la tarea.

No puede "hacer que la gente se preocupe por los plazos" de ninguna manera que produzca resultados positivos.

Es tautológico decirlo, pero los desarrolladores trabajan al ritmo al que trabajan. Esta es su capacidad. La capacidad se puede reducir por muchas cosas, pero no se puede aumentar excepto muy lentamente, y eso tiene más que ver con la experiencia de un desarrollador individual que con cualquier cosa que pueda hacer. Con la excepción de invertir en un presupuesto de capacitación decente.

Decirle a un desarrollador que trabaje "el doble de duro". no funcionará, incluso si parece que lo hizo. Es posible que se haya cumplido un plazo de manera trivial, pero considere qué trabajo no se hizo para cumplirlo.

Lo que viene al quid de la cuestión: una cosa que está bajo control es qué trabajo se hace; con qué se llena esa capacidad. Lo que se prioriza; qué características doradas se recortan a medida. Las tareas más pequeñas y comprensibles tienden a realizarse antes y con mayor calidad. Sin embargo, desglosar funciones grandes en estas tareas pequeñas es competencia del propietario del producto. Asegurarse de que estas características más grandes se especifiquen correctamente puede requerir la alineación con usted como Gerente de Proyecto. Asegurarse de que las tareas se desglosen correctamente puede requerir la participación de usted como Scrum Master.

Pero, ¿gestionar por plazos? Prometer a los clientes lo imposible y luego insistir en que el desarrollo lo atienda no es el mejor punto de partida.

Punto final: recomendaría no medir la productividad individual de los desarrolladores. Simplemente no funciona de esa manera en un entorno de equipo.

Esto es bastante común, especialmente con los nuevos gerentes. Necesitas dejar tu huella, no es un concurso de belleza.

Organice una reunión y establezca algunas reglas básicas, sin importar cuáles sean en este momento, siempre que se rompan. Si las reglas se mantienen, agregue un poco más gradualmente y problema resuelto. De lo contrario, encuentre al peor infractor (pero asegúrese de que no sea alguien a quien no pueda perder porque es posible que no tome medidas disciplinarias legítimas de manera profesional ya que aún no está actuando profesionalmente), tome cualquier acción disciplinaria disponible y haga un ejemplo de ellos. y luego siéntese y observe cómo el resto se alinea.

No recompensas a las personas hasta que te den una razón para recompensarlas, esa es una falacia en la que he visto caer a muchos gerentes. Sí, hace que los empleados te aprecien, pero no hace que te respeten más de lo que lo hizo. Un gerente que es un maestro de las tareas duras y que no teme hacer restallar el látigo eventualmente gana más respeto y simpatía 'real' que uno que no lo hace.

He hecho esto con todos los equipos con los que he tenido un problema, y ​​es una llamada de atención para todos los interesados ​​y pronto me muestra el calibre de los miembros del equipo, lo cual es útil saber por sí mismo. Pero su principal utilidad es que atraviesa la basura y los mimos y pone las cosas en marcha y se logran rápidamente.

Mi sugerencia sería que cambie a un proceso de desarrollo ágil. Sé que dice que es un experto en scrum, pero lo que está haciendo claramente no es el sistema ágil estándar de estimación e iteración que se usa en XP y Scrum. En particular, al tratar de aumentar la "velocidad", está rompiendo por completo el objetivo de la planificación ágil. (La velocidad es la métrica que usa para obtener una estimación precisa de cuánto trabajo puede hacer el equipo actualmente; presionar para que aumente lleva a una inflación de puntos con números más altos pero no más trabajo real realizado, estimaciones inexactas o ambos).

Dentro de los procesos ágiles estándar, el propietario del producto trabaja en cooperación con los desarrolladores para crear historias y luego decide en qué orden se trabajará en las historias. No tiene participación en el proceso de estimación y, si tiene o quiere que las cosas se entreguen en ciertos momentos, su única capacidad para hacerlo es cambiar el orden de las historias para trabajar en algunas antes.

Los desarrolladores trabajan con el propietario del producto para crear historias, pero son los únicos que pueden estimarlas. (Ni siquiera usted, ya sea su gerente o el entrenador ágil, tiene alguna opinión sobre las estimaciones a menos que también esté trabajando en la implementación de historias. No puede ordenarles que hagan algo en menos tiempo). Al final de cada iteración, suma la estimación total de todas las historias que se completaron con éxito y, en general, su estimación para la próxima iteración nunca será mayor que eso. Es particularmente importante que ni usted ni el equipo intenten aumentar ese número; eso es directamente destructivo para su capacidad de estimación porque ya no está utilizando los datos del mundo real que realmente muestran cuánto ha hecho.

Si esto suena como si no hubiera un papel muy importante aquí para un gerente, eso es correcto. Los equipos ágiles que funcionan bien se autogestionan en gran medida, y esa es una gran parte de la razón por la que pueden producir un buen trabajo. También es increíblemente satisfactorio ser un desarrollador en un equipo de este tipo porque ya no tienes un gerente rondando por ti tratando de obligarte a cumplir plazos poco realistas o hacer cosas contraproducentes.

Si decide que realmente quiere ser ágil, le sugiero encarecidamente que busque un entrenador que conozca bastante bien la metodología ágil. Si no hay nadie en su equipo que lo haga, tendría que buscar fuera de su equipo para esto, pero hay muchos consultores que podrían trabajar con usted durante unos meses para ponerlo al día. Los malentendidos sobre cómo funciona Agile, como los que tiene, generalmente conducen a la falla del proceso. (Por favor, no tome esto como un insulto; no hay nada terrible en la falta de conocimiento en un área determinada, siempre y cuando sea consciente de ello y tome medidas para remediarlo, si es necesario).

Bueno, por su pregunta, podría suponer que usted es un gerente de proyecto en un producto de software o algo así.

¿Cómo siente que no se está haciendo el trabajo cuando sabe que hay metodologías ágiles que puede seguir y menciona que las conoce?

¿Cómo es que esto no es perfecto para ti? https://www.mountaingoatsoftware.com/agile/scrum/daily-scrum

Establezca una reunión de sprint diaria de 8 a 8:15. Haga que todos hablen sobre lo que han hecho el último día y establezca un OBJETIVO MUY CLARO PARA EL DÍA ACTUAL. Al día siguiente, haz lo mismo.

En muchos proyectos, las reuniones diarias no eran el caso, ya que el trabajo se realizaba en paquetes semanales, tenía reuniones semanales en las que todos se ponían de pie, hablaban sobre su trabajo y objetivos, y establecían objetivos para la semana siguiente. Puedes hacer eso todos los días.

Si quieren pasar todo el día en facebook y hacer el trabajo durante la noche, es su problema.

Si, durante las reuniones diarias, realmente siente que algunos de los profesionales no están realizando el trabajo de manera eficiente, hable con ellos por separado y trate de comprender su problema. ¿Eres tú el que no está marcando correctamente sus objetivos? ¿Es la carga de trabajo que es demasiado? ¿Son los entregables los que no están entendiendo correctamente?

Disculpe mi sinceridad y si sueno grosero, pero parece que realmente necesita administrar el equipo, sus entregables, objetivos y trabajo.

Me siento un poco reacio a responder ya que no explicas tu posición, pero sinceramente, si sientes que la producción está baja o no es óptima, habla.

Las personas a menudo sienten que el trabajo se está haciendo cuando no es así. Es un problema común cuando no hay principios claros

Como un manager:

Haga una reunión para decirles qué está pasando, qué le está molestando en el lugar de trabajo y pídales cooperación.

Como compañero de trabajo:

Haga una queja con su Gerente. Aparte de eso, no perturbe las relaciones laborales que tiene con sus compañeros de trabajo al hacer su trabajo de Gerente.

Actualizar:

Honestamente, ya que eres nuevo, no sería tan mandón ya que eres nuevo. Ir a la reunión diaria y simplemente decir que los plazos no son cómplices y no siento que sean imposibles y no quiero poner reglas, pero estoy empezando a sentir que no hay otras opciones. Y lo más importante, solicite sugerencias para mejorar la productividad y su experiencia con el trabajo que están realizando.

Aún así, siento que una empresa con 12 desarrolladores (que es un poco mucho) debería tener estándares de gestión, independientemente de si les va a gustar o no.

Recomendaría no intentar sacar conclusiones después del primer día o incluso del primer mes. Parece que está tomando un concepto relativo (algo arbitrario) como la velocidad y usándolo para clasificar a las personas.

Da un paso atrás y relájate, supongo que tienes un poco de tiempo antes de que se espere que hagas milagros.

Trabaje con sus informes e intente facilitar su trabajo.

• ¿Sienten que tienen obstáculos o cuellos de botella?
• ¿Sienten que tienen un trabajo que no agrega valor?
• ¿Sienten que tienen propiedad sobre los plazos proporcionados?
• ¿Entienden cómo el trabajo que están haciendo contribuye a los objetivos del proyecto?

El trabajo de un gerente de proyecto no es mantener a la gente concentrada en la tarea, es hacer que el proyecto tenga éxito. Estos son adultos (supongo), y recomendaría no intentar administrar su tiempo para ellos.

Haga que su trabajo sea ayudarlos primero y los plazos se solucionarán solos.