¿Es realista un gran aumento de velocidad en un entorno Scrum?

89

Recientemente, mi gerente realmente ha estado presionando para usar la velocidad como objetivo y medida de productividad. Actualmente estamos trabajando a una velocidad promedio de 50 puntos de historia. Mi gerente quiere que lo aumentemos en un 40% a 70 puntos de historia (sin aumento en los miembros del equipo). Si no logramos este aumento, quiere que entreguemos un desglose completo explicando por qué.

Toda la idea de medir el rendimiento del equipo por velocidad y usarlo como un objetivo me parece erróneo, pero me resulta difícil explicar por qué. ¿Alguna ayuda? ¿Por qué no es esta la forma correcta de medir e incentivar la productividad?

P2l
fuente
19
Guau. El gerente no entiende qué es la velocidad o piensa que el equipo está aflojando. o ambos. En la próxima reunión de planificación, comprométase con 70 puntos y deje que el equipo le diga los riesgos de falla que causarán
Steven A. Lowe
25
Parece una solicitud tan absurda, que me gustaría que le preguntes por qué cree que esto es posible: si ya estás dando el 100%, ¿espera que des el 140%? ¿Qué pasa si solo haces sprints un 40% más?
Jonathan Rich
20
Se supone que la velocidad es una medida de qué tan rápido puedes hacer las cosas. Si sus puntos de velocidad e historia son exactos, esto le indica que no puede completar toda la cartera de pedidos antes de la fecha límite. Lo racional es aceptar la realidad y eliminar las cosas del trabajo atrasado o priorizar lo que hay allí para que lo que se haga sea lo más importante. O podría cambiar la fecha límite a algo realista.
Michael Shaw
45
Pídale un aumento del salario del 40% si logra esos objetivos, luego aumente sus estimaciones para obtener el aumento del 40%.
mattnz
18
¿No es más bien como pedirle a un corredor de maratón que de repente corra el maratón en 1h25m en lugar de 2h?
Scroog1

Respuestas:

158

Bueno, es perfectamente simple aumentar la velocidad en un 40%: solo agregue un 40% más de puntos a todas sus estimaciones y haga la misma cantidad de trabajo.

Dado que esto es así, debería ser evidente por qué usar la velocidad como un objetivo es incorrecto, solo alienta las estimaciones infladas.

Una respuesta menos simplista es que su estimación ya asume que va tan rápido como puede mientras hace todo correctamente. La única forma de aumentar realmente la productividad en un 40% es trabajar horas extras o no hacer todo correctamente. Ambas cosas aceleran las cosas a corto plazo, pero ralentizan las cosas a largo plazo. Y el largo plazo en este caso no es muy largo, un mes en el exterior. La estrategia óptima a largo plazo es nunca ir más rápido que su ritmo sostenible.

Peopleware habla elocuentemente sobre los problemas de tratar de forzar a los programadores a una mayor productividad, y es un clásico a menudo citado. Pero, en general, no será fácil cambiar la opinión de un gerente que está siguiendo el camino del suyo. Su proyecto bien puede estar en problemas, esto es ciertamente una bandera roja.

psr
fuente
28
Creo firmemente que no hay "rápido y sucio". "Sucio" siempre me hace lento, incluso a corto plazo.
Doc Brown
1
@Paul - Pensé que era bueno. Pero el consejo en su mayoría solo puede ser seguido por los gerentes, y los que podrían beneficiarse de él probablemente no lo leerán. Ni leerlo necesariamente cambiará el comportamiento.
psr
2
Y si está de acuerdo y realmente aumenta la velocidad en un 40%, a otros les parecerá que usted y su equipo no estaban trabajando de la mejor manera. La forma profesional de manejarlo es dar una respuesta directa: "No, no puedo hacerlo". Otra referencia de libro al respecto: "The Clean Coder" de Robert C. Martin.
pablosaraiva
1
"su estimación ya supone que irá tan rápido como pueda mientras hace todo correctamente" Esto es probablemente una suposición incorrecta. Siempre podemos seguir mejorando y optimizando. Los equipos nunca deben suponer que su velocidad estable indica que no pueden mejorar. Pero necesitan observar todo su proceso sistemáticamente y buscar mejoras menores en el proceso.
Curtis Reed
53

Como los comentarios han señalado, la solicitud obviamente es incorrecta en la forma en que se ha formulado. Pero no está realmente equivocado al querer mejorar constantemente la productividad. Como regla, eso es por lo que los gerentes se esfuerzan (y son evaluados).

Dicho esto, los gerentes siempre buscan mejorar el rendimiento, y Scrum and Agile se trata de ser adaptable. Si bien la velocidad es una medida de su ritmo sostenible actual, no debe sentarse en sus laureles. Scrum tiene un lugar para evaluar y cambiar lo que funciona y lo que no funciona en su proceso: la retrospectiva. Si aprovecha eso y ajusta su proceso, la productividad (y posiblemente la velocidad) debería aumentar.

Entonces, ¿estás buscando (en tus retrospectivas) formas de ser más productivo como equipo? ¿Hay algo en tus sprints que consuma regularmente una cantidad desproporcionada de esfuerzo? ¿Se puede abordar? Probablemente no te dará un aumento del 40%, pero 5-10% es un comienzo, ¿no? Cada sprint debe buscar cuellos de botella y abordarlos. Eventualmente, puede acercarse a la meta que él ha establecido para usted.

Matthew Flynn
fuente
77
+1: esta es una buena manera de describirlo al gerente. No puedes aumentar artificialmente la velocidad, pero puedes mirar hacia atrás después de cada sprint y aprender qué puedes hacer para ser más eficiente el próximo sprint.
Kevin
3
Lo más probable es que eliminar los gastos generales del gerente (reuniones forzadas, completar formularios, etc.) probablemente le dé ese 5-10%, fácilmente. ¿Pero cómo convencerlo?
AviD
2
Creo que su respuesta representa un malentendido de la velocidad. No es una métrica absoluta, es un promedio medido durante la vida del proyecto. Lo que es más, los puntos de velocidad en sí mismos no representan el trabajo realizado, sino medidas aproximadas de complejidad. También son promedios, y una tarea de punto bajo puede requerir más tiempo que una tarea de punto más alto. Parece un poco sin sentido pedir "más" y representa un malentendido fundamental. El gerente básicamente está pidiendo una fecha límite fija.
Ricardo Gladwell
3
@RicardoGladwell - Cuando dije "la solicitud obviamente es incorrecta", estaba reconociendo que se trataba de una comprensión incorrecta de cómo funcionan los puntos de la historia. Simplemente estaba sugiriendo que lo que el gerente realmente quiere es que el equipo mejore la productividad, y Scrum proporciona un medio para hacerlo. Además, hay diferentes opiniones sobre lo que representan los puntos de la historia: la complejidad es una de las más comunes. La mayoría de los equipos con los que he trabajado los han hecho corresponder un poco con el nivel de esfuerzo. Una tarea simple con mucha cantidad ya no se considera simple.
Matthew Flynn
1
Usted menciona que un aumento de la velocidad de "5-10% es un comienzo", pero esto parece compartir el malentendido del gerente de lo que significa "velocidad creciente" que describí.
Ricardo Gladwell
26

TL; DR

La velocidad es muy útil para estimar horarios o generar valores de planificación, y también puede ser un control detectivesco significativo para evaluar los cuellos de botella del proceso o los cambios en la capacidad del equipo. Sin embargo, no es una medida válida de productividad.

Cuando se confunde velocidad con objetivos de gestión

"Velocidad" es un rango que expresa la capacidad promedio de un equipo durante un período histórico. Es un análisis estadístico del rendimiento pasado, que luego se puede utilizar para proyectar estimaciones probabilísticas de la capacidad de carga de trabajo o tiempos de ciclo futuros. Esto está en marcado contraste con un "objetivo de programación", que es un objetivo administrativo que establece una línea de tiempo u objetivo para fines de planificación.

Los gerentes de proyectos ágiles con experiencia saben que el uso adecuado de la velocidad es determinar si un equipo tiene la capacidad sostenible de cumplir con los objetivos de programación definidos por la administración. A veces la respuesta es sí, y todos están felices. A veces la respuesta es no, en cuyo punto el triángulo de hierro obliga a las decisiones comerciales sobre el alcance, el costo, el tiempo y la calidad.

Evalúa tus opciones políticas

Tenemos una velocidad promedio de 50 puntos de historia ... Me han pedido que la aumente en un 40% a 70 puntos de historia (sin aumento en los miembros del equipo).

Suponiendo que sus prácticas de estimación son sólidas y que su velocidad es razonablemente estable, su gerente no se alegrará de ajustar la escala de estimación o establecer objetivos de gestión que no se basen en el rendimiento histórico. Como señala correctamente, esto es fundamentalmente un problema de capacidad .

El límite de capacidad puede estar relacionado con la cantidad de personas en su equipo, o puede ser una limitación de sus procesos organizacionales. Por supuesto, agregar más personas tampoco siempre agrega la capacidad real del proyecto; vea la Ley de Brooks para más información sobre este error común.

El problema que enfrenta es político. Por el tono de su publicación, parece que su gerente quiere ver un aumento en la productividad sin realizar ningún cambio real en la capacidad subyacente del equipo. Por lo tanto, las soluciones también son políticas y en gran medida de naturaleza educativa.

Si usted es una tienda Scrum, pídale a su Scrum Master que aborde este problema a través de los canales marco apropiados. La preparación del trabajo atrasado y las retrospectivas de Sprint son a menudo las oportunidades ideales de inspección y adaptación para este problema en particular.

Si no es una tienda Scrum, debe decidir cuál es la forma correcta de abordar sus inquietudes dentro de su organización. Si está en buenos términos con su gerente, incluso podría prestarle una copia de Agile Estimating and Planning para que los dos discutan durante el almuerzo.

Si todo lo demás falla, prepárate para una marcha de la muerte repasando tu currículum y haciendo tu mejor esfuerzo profesional hasta que el proyecto explote. El 68% de los proyectos de TI fracasan ; a menos que los objetivos de gestión estén sólidamente basados ​​en la capacidad organizativa, el suyo probablemente sea uno de ellos.

CodeGnome
fuente
la calidad no es una variable de ajuste: por eso hablamos de triángulo de hierro, no de cuadrado de hierro. En otras palabras, cuando alguien intenta reducir la "calidad", causa estragos en los retrasos (entregas más largas), el alcance (las características no funcionan y, por lo tanto, no se realizan) ... y los recursos (los desarrolladores están frustrados y se van). Buena respuesta al lado de ese minuto.
kriss
1
@kriss Quality puede, de hecho, ser parte del triángulo. A veces se considera parte del "alcance", o en algunos triángulos es un vértice real que indica que es una restricción primaria. Vea el triángulo azul dentro de la Estrella PMBOK como un ejemplo concreto, o la Evolución del Modelo de restricción del proyecto para obtener algunos detalles sobre este tema. Por favor mencione esto en PMSE para más información.
CodeGnome
Esta es una discusión que ya tuve con otros agilistas. En resumen, en lo que no estamos de acuerdo es que PMBOK es un recurso ágil válido. Se originó con el modelo de cascada y es ortogonal a ágil. Es sobre todo compatible, pero todavía hay algunos problemas. Considerar la calidad como una variable de ajuste es uno. Tal como lo veo (y no estoy solo) usando (tratando de usar) Calidad como una variable de ajuste interrumpe todo el proceso Ágil. Pero debería ser una cuestión propia.
kriss
Pregunta publicada aquí pm.stackexchange.com/questions/11489/…
kriss
21

¿No entiendo qué papel tiene su gerente en el equipo Scrum? ¿Es él un entrenador? ¿Es dueño de un producto?

Si está dentro del equipo como un entrenador o tal (trabaja en una tarea de desarrollo), puede preguntarle por qué subestima su propia productividad, porque parece que ese no era el caso para otros miembros del equipo. Si cree que puede asumir personalmente 30 puntos de historia más en cada iteración, permítale mostrarlo.

Más probable: él está fuera del equipo, ¿tal vez el dueño del producto? Si es así, debería entender hacer una solicitud tan estúpida que simplemente detuvo la agilidad.

Una regla básica es que el propietario del producto establece el objetivo mientras que el equipo establece lo que se puede hacer en una iteración. No hacerlo conduce al círculo de hierro clásico y bien conocido: recursos, velocidad, características. ¡Elige dos! No puede elegir tres de ellos a la vez (y recuerde: la calidad no es una variable de ajuste, tratar de cortar las esquinas a través de la baja calidad empeorará las cosas).

Si no quiere cambiar el objetivo actual, ¿quizás se pueda alcanzar un aumento del 40% en la productividad reclutando más personas para el equipo? ¿Tal vez invertir en algún entrenamiento avanzado para algunos miembros del equipo? Los equipos también pueden ganar velocidad con el tiempo a través de la mejora continua, pero ciertamente no por decisión arbitraria.

Intentar cambiar la velocidad de un equipo es como tratar de cambiar el tamaño de una habitación. Se puede hacer, pero básicamente necesitas cambiar la habitación.

¿No tienes algún Scrum Master, o alguna otra gente con conocimiento básico de Scrum que pueda explicarle eso?

kriss
fuente
15

En este caso, el gerente ha tomado la dirección equivocada después de recibir una estimación honesta y fiel del equipo. Se supone que el gerente debe dirigirse a la parte interesada y hacerles saber que sus requisitos no se pueden completar en el tiempo solicitado. El gerente / analista debe priorizar cuáles de las características DEBEN incluirse y las demás que pueden esperar (aunque solo sea un par de semanas). Si la parte interesada no es razonable, entonces podría requerir la participación de gerentes superiores, lo que generalmente puede ser desafiante y requerir otro conjunto de discusiones.

Si estuviera en su lugar, se me ocurriría un caso detallado de por qué el proyecto TOMARÁ tanto tiempo como se estimó. También trate de identificar artículos de bajo rendimiento. Encuentre los elementos que no agreguen mucho valor y requieran esfuerzos de programación sustanciales y haga un caso para eliminarlos del sprint. También proponga un enfoque iterativo que ofrezca "X" en la fecha "Y" y asegúrese de que sea factible, luego proponga una iteración de seguimiento que les permita obtener los elementos restantes.

Básicamente, alguien necesita decirle a las partes interesadas qué pueden esperar recibir antes de la fecha límite y que incluye la mayoría de sus requisitos. y que en la siguiente versión tendrán los elementos restantes. Si el cliente no es razonable, entonces la alta gerencia debe involucrarse, el gerente debe poder hacer que esto suceda.

Sin embargo, si el cliente se prometió en exceso y nadie ha hablado hasta ahora, será una batalla cuesta arriba. Desafortunadamente, esta no es una situación poco común.

hanzolo
fuente
1
"estimación honesta y fiel" puede ser el problema.
JeffO
@JeffO - Podría ser, es por eso que recomendé hacer el caso para justificar las estimaciones ... cuando intenten hacerlo, se darán cuenta de que han inflado sus estimaciones o de que realmente no tienen la capacidad
Hanzolo
9

Parece que te enfrentas a dos problemas.

La parte de medir la velocidad que le molesta es probablemente que la medida es el costo . Lo que realmente quieres mejorar es el valor . Desafortunadamente, medir el valor del software es notoriamente difícil y subjetivo. Aún así, incluso una métrica imperfecta y subjetiva puede ser útil. Podría ser que el problema real no sea que su equipo necesita escribir más código, sino que las historias deben ser más valiosas.

El otro problema es que, según su cuenta, su gerente esperaba un aumento del 40% en la productividad. No se indicó en su pregunta el contexto de esta solicitud. Podría ser un buen carácter si desea un deseo para que su equipo mejore. O podría ser una indicación no tan sutil de que su gerente cree que su equipo tiene un bajo rendimiento.

editar: según su comentario, la situación se ve mal. Parece que su empresa está sentando las bases para despedirlo a usted y a su equipo (tal vez su gerente también). Te sugiero que busques otro trabajo.

Aaron Kurtzhals
fuente
3
Desafortunadamente, fue una solicitud seria, redactada en el sentido de que no veo ninguna razón por la que no pueda lograr esto (¡pero no le diré cómo!). Entonces, la implicación es que él no cree que estén trabajando lo suficiente o que no sean tan competentes como deberían. Luego empeoró cuando estaba de vacaciones y el propietario del producto le dijo al equipo que habría serias repercusiones si no lo lograban. Así que ahora también tengo que preocuparme por un equipo muy preocupado (de quien realmente creo que es un gran equipo).
P2l
44
+1 para "salir de Dodge". A veces es la única manera (aunque con menos frecuencia, mejor).
Michael
9

Despidelo. Es decir, vaya por encima de su cabeza y explique que ha perdido toda la confianza de su equipo, y explique que no tiene valor para el negocio. Explique que los gerentes con este nivel de incompetencia son mucho más fáciles de reemplazar que el equipo a continuación.

No hay una buena razón para soportar un administrador así, pero eso no debería significar automáticamente que los desarrolladores deberían renunciar. No hay necesariamente algo malo con el negocio, solo con este individuo. Arregla ese problema.

Y para evitar cualquier silencio de la alta gerencia, deje en claro que esto no es un error perdonable. Indica que el gerente responsable no comprende el equipo que está administrando. Eso no se presta a la fijación, ni es necesario hacerlo en el mercado laboral actual. Los gerentes son eminentemente reemplazables al igual que los entrenadores deportivos. Los propietarios no despiden equipos.

Ahora, esto podría parecer una estrategia que puede ser contraproducente. Pero considere: si la alta gerencia se pone del lado de su gerente, independientemente de eso, ya estaría en una posición perdedora de todos modos. Entonces, si solo considera las situaciones en las que aún no está en esa posición perdedora, el resultado probablemente será mucho más positivo. El riesgo real es que la alta gerencia simplemente despida a todo el equipo, incluido el gerente. Solo usted puede estimar ese riesgo. Al parecer, su producción es deseada, de lo contrario no pedirían más, pero ¿a qué precio?

MSalters
fuente
55
En otras palabras, levanta las manos en el aire, llora y haz un ataque. Este tipo de actitud nunca resuelve problemas. Hay formas mucho mejores de manejar la situación.
MrFox
No. Lamentos o ataques son acciones dramáticas. Eso puede ser ignorado. Lo que propongo es un ultimátum. O este gerente se va o el equipo se va. Sin drama, solo lógica comercial fría. No es apto para el trabajo, y es tarea de la alta gerencia actuar en consecuencia. Pero su opción preferida podría ser ignorar la situación, si se lo permites. Es por eso que debes eliminar esa opción.
MSalters
@nathanhayfield Típico? Creo que el equipo estaría compuesto por una variedad de personalidades y personas. Los perezosos deben dirigirse individualmente, no una solicitud general para el equipo.
James Khoury
1
@MSalters Hay muchas personas en diferentes niveles de negocio que no entenderán ciertas cosas. El enfoque correcto es mitigar el conflicto y educar a todos los involucrados. Tal vez este gerente no entienda a Agile, pero puede tener otras cualidades redentoras (que podrían ser mucho más importantes). Como profesional, debe aprovechar al máximo cada situación y trabajar con cada tipo de personalidad, porque eso es realmente constructivo y útil a largo plazo. Hacer lo que estás sugiriendo no escala.
MrFox
3
@MrFox: se supone que los gerentes directos entienden la programación; de hecho son la capa más directamente responsable de ello. Se supone que los miembros del equipo son expertos en la materia y la gerencia de nivel superior está más lejos de la acción. Por lo que este director, en una posición en la que está haciendo afirmaciones acerca de los horarios, demuestra que no entiende lo que es quizás su tarea más importante. Si el mercado laboral era escaso, conseguir un mejor gerente podría ser problemático. Pero hoy puedes encontrar a alguien mejor.
MSalters
6

Mi experiencia es que ha sido muy, muy difícil aumentar la velocidad real de un equipo, dado que ni el equipo, el dominio del problema o la pila de tecnología cambian.

Donde pude lograr aumentos, ha sido una cuestión de:

  • limpieza de la deuda técnica; asegurándose de que todo esté ejecutando la versión correcta (¡no necesariamente la última!), que el código esté bien factorizado y que no haya redundancia en el sistema (código duplicado, código no utilizado, etc.)

  • mejorar las prácticas; emparejamiento siempre que sea posible (sí, he descubierto que aumenta la velocidad), tomarse el tiempo para refactorizar agresivamente (¡lo mismo!) y ser despiadado con respecto al alcance y el enfoque

  • encontrar y / o comprar las mejores herramientas para el trabajo (por ejemplo, ReSharper para .NET vale su peso en oro, desarrollo de Airbrake y Splunk para Ruby, etc.)

Estoy de acuerdo con otros aquí que dicen que su gerente que solicita un aumento arbitrario de la velocidad es una señal de alerta. Estaría buscando otro trabajo como una alta prioridad.

Duncan Bayne
fuente
3

Su gerente le pide (o le dice) a su equipo que trabaje horas extra. Si bien eliminar los cuellos de botella y aumentar la eficiencia puede mejorar un poco su velocidad, la única forma de obtener ese aumento (40%) es trabajando más horas, ya que necesita acumular más unidades de trabajo en ese período de tiempo.

Tomemos un escenario.

Para una interacción de dos semanas, digamos 10 días. La utopía sería de 8 horas al día, con un punto de la historia abstraído a un día de trabajo. Entonces, desde la cima, su velcoity sería 8. Pero, en realidad, la gente probablemente recibe 6 buenas horas al día con correo electrónico, reuniones, descansos en el baño, etc. Así que ahora tiene un costo de 6 por desarrollador. Entonces su línea de base es 6. Digamos que quiere que las personas trabajen horas extras, ahora allí a las 10 horas al día. Entonces, eso sería 10 puntos de velocidad por desarrollador.

Su velocidad siempre fluctuará, tal vez fue baja porque tuvo que lidiar con muchos errores durante esa iteración, tal vez faltaron requisitos, tal vez alguien se enfermó durante unos días. Tal vez fue alto porque el trabajo fue sobreestimado o su equipo invirtió horas adicionales.

Pero si estás en un estable 50, realmente para llegar a 70 requerirá horas extra.

Jon Raynor
fuente
2

El problema con la velocidad es que es una variable dependiente, una salida medida de su proceso de desarrollo. Exigir aumentar la velocidad en un 40% es como tratar de llegar al trabajo antes gritando a los autos que vayan más rápido. La velocidad aumenta al alimentar más combustible y aire al motor o al obtener un automóvil más rápido, además de encontrar una ruta con menos tráfico.

Trabajar más horas no aumenta la velocidad si la mide correctamente, por ejemplo, en puntos característicos por hora de desarrollador. Solo funciona si mide puntos por día y luego redefine lo que es un "día" en la mitad de la medición. Esto proporciona solo la ilusión de velocidad.

Un aumento en la velocidad requiere mejorar las variables independientes en el proceso de desarrollo; computadoras y compiladores más rápidos, un sistema de construcción más eficiente, un mejor proceso de diseño, desarrolladores más capaces, un mejor espacio de trabajo, una motivación súper inteligente. Una mejora del 40% requeriría cambios muy significativos.

Pregunte si su gerente consideraría la ubicación conjunta de su equipo en oficinas cerradas alrededor de una sala de trabajo común, la compra del hardware de desarrollo completamente nuevo del equipo o la contratación de un par de desarrolladores realmente senior para guiar al equipo si eso le daría su 40%. Si no hay recursos disponibles para mejorar las entradas a su proceso de desarrollo, eso prácticamente descarta un interés sincero en mejorar. Esto deja a su gerente en ingeniería inversa para descubrir qué es lo que realmente lo motiva, que sería el tema de otro tema.

SeattleCplusplus
fuente
1

Bueno, estoy un poco sorprendido de que las otras respuestas tomen en serio la solicitud del jefe. Alguien que exige un aumento del 40% en la productividad no sabe lo primero sobre el desarrollo de software.

Todavía disfruto leyendo a Phil Factor sobre este tema:

Hay dos rutas básicas en la gestión de TI. Puede aprender su oficio a través de la sangre, el sudor y las lágrimas y ascender gradualmente en la escalera, en función de la credibilidad que ha obtenido de los conocimientos técnicos y los proyectos exitosos que se han ganado con esfuerzo. Alternativamente, puedes ponerte un traje y corbata afilados, aprender la jerga y hablar sin problemas hasta la cima.

Ambas rutas parecen igualmente efectivas. Tratar con la última raza ciertamente puede causar algunos momentos de consternación e incredulidad ... desesperación incluso ... y algo de eso está documentado en estas historias.

Sin embargo, es fácil ponerse triste y amargado cuando uno encuentra incompetencia técnica en puestos de poder y asediar a todos los gerentes con el mismo cepillo. Phil desaconseja eso. La mayoría de los gerentes trabajan duro y contribuyen bien a la empresa, e incluso los gerentes pobres pueden recibir capacitación según el estándar requerido, si solo sigue algunas pautas simples. Es parte de la responsabilidad de su equipo ayudar a su gerente a funcionar de una manera que beneficie a todos.

En última instancia, si no puede entrenarlos, promocionarlos o evitarlos, tal vez pueda aprender a amarlos solo por su contribución involuntaria a la rica comedia del lugar de trabajo.

El consejo de no volverse "triste y amargado" es lo mejor que puede obtener. No luches contra un jefe técnicamente incompetente por cuestiones técnicas. Simplemente lo verá como un ataque personal.

Andomar
fuente
Bueno, creo que este tipo de depende del modelo de gestión que suscriba. Líder de entrenamiento: un experto reconocido que se ensucia las manos y les enseña a otros cómo mejorar, pero en general sigue siendo "el Gurú". Director de Liderazgo: el "experto" que lo sabe todo (o cree que lo sabe) y solo da órdenes y le dice a la gente qué hacer. Liderazgo por delegación: puede no ser el experto, confía en su experiencia y facilita. Liderazgo de apoyo: la animadora del grupo ayuda a desarrollarlos, motiva, persuade al equipo de que pueden hacerlo y los ayuda a lograrlo.
Curtis Reed
0

Su gerente ha entendido mal el uso de la velocidad. No es una métrica y no es un objetivo. Su propósito es la calibración de la carga de trabajo del equipo por sprint.
Si lo piensas, tu velocidad emerge de una mejor suposición, que vuelves a medir después de cada sprint. Por lo general, a medida que pasa el tiempo, debería volverse algo estable. Pero eso no cambia el hecho de que es un subproducto de lo que su equipo está haciendo realmente: crear valor para sus clientes.

La razón por la que está mal usarlo como un objetivo y / o una métrica es porque eso lo convertiría en una métrica de vanidad. Se vería bien en papel, pero no haría absolutamente nada para reflejar si sus productos satisfacen o no las necesidades de sus clientes. Y eso es lo más importante (espero).

Stefan Billiet
fuente
Por lo que puedo decir, esto ya se explica en otra respuesta : "un rango que expresa la capacidad promedio de un equipo durante un período histórico. Es un análisis estadístico del rendimiento pasado, que luego puede usarse para proyectar estimaciones probabilísticas de la carga de trabajo futura". capacidad o tiempos de ciclo ... "
mosquito
@gnat parte de eso sí, aunque esa respuesta no dice nada sobre el uso de la velocidad como una métrica de vanidad, lo que sigue siendo importante, porque para muchos gerentes hacen cosas estúpidas basadas en números proxy. El OP dijo que sentía que estaba mal, pero no podía explicarlo. Sentí que el término métrica de vanidad (de The Lean Startup) ofrecía una buena explicación.
Stefan Billiet
-1

En cuanto a mi experiencia y yendo directo al grano.

Primero, podría inflar la estimación, pero eso no significa que esté haciendo más.

Segundo (premisa: sin inflar, solo enfocándose en la velocidad del equipo),

Intenta encontrar las habilidades dentro de tu equipo. ¿Están trabajando en lo que son mejores? ¿Necesita un arquitecto de sistemas para tomar decisiones difíciles con respecto a la construcción de la aplicación y cosas complejas? ¿Cómo está gastando el equipo sus esfuerzos? ¿Pasan tiempo investigando soluciones para sus problemas, refactorizando, tomando decisiones comerciales o qué?

¿Son cómodos, enfocados y estimados? ¿Qué sigue para ellos?

Esto no es "estoy sobre los límites" ... es más como una pregunta para todo el equipo "¿Estamos en los límites?" y "¿Cómo podemos empujar los límites?" ...

Tengo equipos líderes de alto rendimiento (para la primera construcción y / o migraciones) ... la motivación del equipo es la clave del éxito ... y planificar cómo sería la base de la aplicación es esencial. A veces, yo o un compañero de equipo tomamos el papel de Arquitecto de Sistemas y decidimos cómo y dónde debe ir la "cosa".

A veces, cuando veo que mis compañeros de té están perdiendo eficiencia, trato de romper e invitarlos a tomar una cerveza o algo que les guste. Esto resuelve cualquier conflicto y al día siguiente vuelven a enfocarse.

DE VENTA...

Si explicar las razones por las que no puede aumentar la velocidad es difícil, use el ROI.

Scrum se centra en lo que es más importante para el cliente. Teóricamente las tareas más rentables.

Si sus problemas están relacionados con la venta del esfuerzo de desarrollo, ¿qué cree que vende cuál es el ROI del esfuerzo de desarrollo? Si puede probar que su equipo trabaja con un ROI alto, ¿quién lo va a interrogar? Además, cada equipo tiene sus límites si el equipo ha encontrado su "tamaño de confort", intente mes a mes un ligero aumento, si no pudieron terminar todas las tareas este es (probablemente) el límite.

Muestre el historial de las tareas, los ingresos por beneficios (si están disponibles), el punto de la historia que ha utilizado y demuestre que LA PRODUCTIVIDAD NO ES EL ESFUERZO DEL EQUIPO es un cálculo determinado por el equipo para evaluar la complejidad y quizás el momento de obtener algo hecho

Marcos Lima
fuente