Caíste en el mito de que los equipos se autogestionan y ahora estás atascado con el desagradable hecho de que la mayoría de ellos no lo hacen.

Sí, el 10% de los mejores programadores se autogestionan muy bien. Eso es parte de lo que los convierte en el 10% superior. Pero la realidad es que la mayoría de las empresas no tienen programadores en el 10 % superior. A la mayoría de los programadores les gusta fingir que son estrellas de rock que merecen un trato especial, pero la realidad es que la mayoría no lo es.

Así que primero tu error es que entregaste toda tu autoridad, lo cual es muy, muy difícil de recuperar. Siempre es más fácil empezar de manera más estricta y relajar las cosas a medida que la gente produce que al revés.

Confió en que sus desarrolladores produjeran y no lo hicieron, entonces, ¿cómo lo soluciona? Primer paso, deja de confiar. Sí, han abusado de su confianza (generalmente cuando las personas piensan que están siendo estafadas por otros, confíe en su instinto) y necesita controlarlas.

Primero debe comprender por qué las estimaciones están tan alejadas. Debido a que ha realizado un trabajo de gestión tan deficiente, hay muchas razones por las que será difícil obtener la información que necesita para solucionar el problema porque actualmente no está solicitando ninguna información. Rutinariamente podrían estar prometiendo lo que no pueden cumplir incluso trabajando duro. O podrían estar prometiendo lo que creen que quieres escuchar y holgazaneando porque no hay inconveniente en no cumplir con las expectativas. Entonces, antes de que pueda arreglar algo, necesita saber si podrían cumplir con la fecha límite si quisieran o si trabajaron las horas reales que deberían trabajar (al menos 40).

Creo que lo mejor que puedes hacer, dada la ridícula cantidad de libertad que les diste, es comenzar con reuniones diarias a las que todos deben asistir y horarios centrales en los que todos deben estar presentes (podría ser de 11 a 3, no tiene que ser de 9 a 6). . Todos los días, cada persona debe ponerse de pie y decir qué progreso hizo el día anterior y qué problemas tiene actualmente y cómo eso podría afectar la fecha límite. Obtienes lo que esperas y, francamente, no esperabas nada.

Así que ahora tienes que empezar a hacer preguntas. Uno de los beneficios de la reunión diaria es que nadie quiere informar que no hizo nada ni avanzó el día anterior. Entonces, si el problema realmente es que te están jugando, solo tener la reunión diaria debería comenzar a ver más progreso. Cuando hay un problema que impide que alguien progrese (por ejemplo, la persona que trabaja en un módulo al que debe hacer referencia no progresa o no se presenta a trabajar hasta las 3), depende de usted eliminar los obstáculos que tiene que superar. haciendo progreso.

Pero también es probablemente cierto que las estimaciones de tiempo están equivocadas. Por lo tanto, también debe observar cómo estima las tareas. También debe darse cuenta de que la estimación del tiempo es difícil y que es posible que deba mantener registros de las estimaciones contra el tiempo real para mejorar la estimación. Las estimaciones grupales también tienden a ser más realistas, ya que los sobreestimadores tienden a ser derribados por los subestimadores. Para obtener estos datos, debe informar el tiempo por tarea para poder compararlo con la estimación. Conviértalo en un sistema de informes simple que no tome más de 5 minutos al día para completar. Y hágales saber que se está utilizando para mejorar las estimaciones para futuros sprints. Es posible que también deba cambiar específicamente su formulario de estimación de tiempo para incluir tiempo para pruebas unitarias, comunicaciones, control de calidad y corrección de errores de control de calidad, implementación, etc.

Ahora, debido a que abdicó de sus responsabilidades como gerente, tendrá cierto rechazo a lo que son expectativas razonables. Bueno, cualquiera que no dedique cinco minutos a completar una hoja de tiempo o que no pueda manejar una reunión diaria (incluso las tiendas Agile hacen esto) y las horas principales no es alguien que desee emplear a largo plazo de todos modos. Estas no son expectativas irrazonables. Hay más en el trabajo que hacer lo que quiere cuando quiere hacerlo y si trabaja en equipo, no puede permitir que una prima donna (que en realidad es solo una programadora promedio y bastante reemplazable) le impida realizar su trabajo. .

Tengo algunos pensamientos aquí

1. Crees que estás liderando, pero ¿lo hace el equipo?La razón por la que pregunto es que una vez estaba contratando para una empresa en la que mi gerente me dijo explícitamente que todos los desarrolladores estaban al mismo nivel, pero uno de los desarrolladores se consideraba el líder, cuando se trataba de un problema y un problema. solo que quería que todos usaran espacios en lugar de tabuladores y pusieran comentarios después de la línea de código en lugar de arriba. Ninguno de los otros desarrolladores apoyó esto, pero sintió que tenía derecho a insistir en que lo hiciéramos (y se negó a discutir el tema). Sin embargo, cuando realmente se necesitaba liderazgo, no se lo encontraba por ninguna parte. Por ejemplo, me pidió que tomara posesión de un subsistema y se negó a tomar partido cuando el otro desarrollador quería desmantelar mi sistema bien diseñado por algo que, en mi opinión, era menos fácil de mantener. Entonces, en este caso, ignoré su "liderazgo" en el formato del código. Dirija, siga o quítese del camino, pero no insista en liderar solo cuando sea algo trivial o estúpido. Además, asegúrese de que realmente ocupa el papel de liderazgo que cree que tiene.
2. ¿Existen otros factores que están afectando sus estimaciones que están fuera de su control? ¿Sus desarrolladores cargan con un montón de código de mierda para mantener/construir? Es imposible estimar bien en estas condiciones. Puede ser que por alguna razón (y esperemos que no sea usted), sus desarrolladores no pueden limpiar los puntos débiles cuando se encuentran. Si se les impide solucionar los problemas subyacentes y sienten que están metidos en el fuego para cumplir con las estimaciones que nadie podría hacer con precisión, entonces se mostrarán reacios a poner por escrito que esto es lo que está sucediendo. .
3. ¿Está haciendo lo suficiente para asegurarse de que se eliminen los obstáculos? Descubrí que en las empresas que dicen que señalar con el dedo no es aceptable, esto significa "no haga olas cuando no está obteniendo los recursos que necesita", no "no se le culpará cuando no pueda hacer plazos porque alguien no te consiguió lo que necesitas". Manténgase al tanto de los expertos en la materia, los diseñadores, etc., que están más adelantados que sus desarrolladores. Cuando un recurso no llega según lo programado, puede tener un enormeimpacto, incluso en los desarrolladores que pueden cambiar de tarea en respuesta. Además, descubrí que algunos diseñadores no tienen ni idea de lo que hago con un archivo una vez que sale de sus manos, por lo que tomará más tiempo para manejar su trabajo. Muchos desarrolladores no tendrán esto en cuenta, especialmente si no es socialmente aceptable en su equipo darse cuenta o si nunca antes han trabajado con ese diseñador.
4. ¿Están los desarrolladores, de hecho, incumpliendo sus plazos? He estado en situaciones en las que las especificaciones eran realmente confusas y mis solicitudes de aclaración no recibieron mucha respuesta. Una vez que se creó algo, surgieron más requisitos, y estos se informaron como "errores" en relación con las funciones que ya había creado, no como una nueva funcionalidad. Además, todos pueden ser realmente insistentes en que la forma en que el desarrollador dice que va a consumir más tiempo es la única forma de construirlo. Una vez que las personas lo han visto, deciden que después de todo no era bueno y quieren volver atrás y reconstruirlo de alguna otra manera. Construir una característica dos veces es construir dos características, y debes verlo de esa manera.

Dicho todo esto, no veo que nadie haya respondido realmente a su pregunta. La respuesta está en el repositorio. Mire para ver qué personas se registran y con qué problemas se relacionan sus registros. Eso te puede dar mucha información sobre lo que está pasando. Si los diseñadores utilizan una ubicación para colocar activos, vea qué está listo y qué falta. Si su construcción es buena y sabe cómo construir el producto, constrúyalo y vea dónde está.

Si está seguro de que es bueno en los otros puntos, y realmente siente que es importante que todos usen su registro de tiempo, debe darse cuenta de que debe lograr que todos asoman la cabeza por encima del parapeto al mismo tiempo. porque nadie quiere ir primero. Esto significa que debe estar preparado para poner su pie en el suelo con algunas consecuencias reales por no hacer esto, sin importar quién sea el "perpetrador" (o no perpetrador, según sea el caso). Piensa largo y tendido si quieres "ir allí".

Una cosa a considerar es que si usted es un líder un poco "húmedo", puede haber algunos en su equipo que estarán muy agradecidos si brinda algo de liderazgo, pero debe brindarlo en todos los ámbitos, no solo en esta cosa

Usted aborda muchos problemas diferentes en la pregunta.

El propósito

Comenzaría con su propósito de preparar todo el asunto. ¿Su objetivo principal es saber cómo avanza el trabajo para tener una mejor visibilidad de lo que está sucediendo? O tal vez quieras controlar a tu equipo hasta cierto punto. O lo tratas como la base del sistema de recompensas. (Usted menciona los tres.)

Comience respondiendo esta pregunta, ya que las soluciones para abordar cada una de ellas serían diferentes.

Conociendo el trabajo

Si el objetivo principal es conocer el progreso, recomiendo enfáticamente la visualización como una herramienta que generalmente hace milagros. Las herramientas simples, como los tableros de tareas o los tableros kanban , no solo ayudan a los líderes a obtener el estado de las tareas que se realizan en un equipo, sino que también mejoran enormemente el conocimiento sobre el trabajo entre el equipo.

Es más, son divertidos. Significa que, por lo general, es bastante fácil introducirlos en el equipo. Sin embargo, el truco consiste en hacer que las personas trabajen con la pizarra de manera constante. En realidad, el mayor riesgo de trabajar con la placa es que no esté actualizada . La diferencia entre la herramienta de administración de tareas junto con el rastreador de tiempo y el tablero de tareas/kanban es que, en el último caso, aprende sobre nuevas tareas en el tablero, por lo que va allí de todos modos: existe un incentivo natural para actualizar la tarea cada vez que cambia su estado.

Controlando el equipo

Mencionas la confianza un par de veces. Al mismo tiempo señala la necesidad de controlar a las personas. Si bien no diría que tiene que elegir uno sobre el otro, creo que al menos debe saber en qué dirección se dirige.

Si elige confiar, no obligaría a las personas a rendir cuentas de cada hora de su trabajo todos los días a menos que trabaje a tiempo y materialmente y esta es una información básica que necesita para saldar cuentas con sus clientes.

Me centraría más en el flujo de trabajo como un todo, por ejemplo, medir la rapidez y la fluidez de los elementos de trabajo que se desplazan desde la acumulación hasta la finalización, y prestaría atención a los elementos que están atascados por cualquier motivo. Si tiene un elemento de trabajo que está en desarrollo mucho más tiempo de lo normal, definitivamente es una llamada para investigar el caso y saber qué está sucediendo. O encuentra un problema que abordar o, si alguien lo defrauda, ​​también recibe una señal clara al respecto.

Esto también significa que no impone una contabilidad de trabajo muy estricta en el equipo, lo que debería apreciarse. Más aún, su equipo no parece ser un gran fanático del enfoque actual, dado que no actualizan los datos con bastante frecuencia.

Recompensas

En cuanto a la información de la que estamos hablando aquí, desaconsejaría encarecidamente su uso como base para cualquier sistema de recompensas.

En primer lugar, soy un gran admirador del trabajo de Dan Pink sobre la motivación . En realidad, como mencionaste las recompensas, no creo que el dinero motive a las personas de la forma en que solíamos pensar. La motivación es intrínseca y muy individual.

Lo que aconsejaría aquí es aprender qué impulsa a su gente y tratar de abordar estos puntos en lugar de construir un sistema de recompensas único para todos, que generalmente introduce muchas más emociones negativas y comportamientos disfuncionales que cualquier cosa positiva.

Peor aún, si basas la recompensa en el trabajo realizado individualmente por los miembros del equipo, desincentivas la ayuda, la aglomeración de problemas y el trabajo colaborativo. Si terminé el 90%, es probable que luche solo con el resto en lugar de pedir ayuda (incluso si es lo más razonable y eficiente) porque temo que no será "mi" éxito. sino "nuestra". Otra perspectiva podría ser que no estoy dispuesto a ayudar ya que tengo mi propio trabajo que hacer y no estoy seguro de que lo que me preguntas no sea una especie de pantano donde perderé mucho tiempo.

En general, desaconsejaría el uso de datos que obtiene de los sistemas de seguimiento de tareas para recompensar, motivar o incentivar a las personas.

Haría la observación de que, si bien ha utilizado alguna terminología Agile/Scrum (Sprints, estimación) e indica que no utiliza un stand-up diario, sin embargo, algunos aspectos de lo que está haciendo parecen más de mando/control (" Asigno tareas a los desarrolladores / Saco o pongo tareas..")

Si desea tener un equipo autoorganizado, que (de manera más crítica) identifique y resuelva sus propias fallas (como completar el 50-60% del trabajo en el Sprint), entonces probablemente tendrá que ir más allá en el camino Agile/Sprint. , lo que significa darle más control al equipo.

Los puntos clave serían:

• el equipo necesita establecer sus objetivos de Sprint (no tú)
• el equipo en conjunto necesita estimar (no los individuos)
• el equipo necesita monitorear su propio desempeño (no usted)

Si tiene una reunión "retrospectiva" bien facilitada para el equipo, deben identificar el hecho de que no alcanzaron sus objetivos y, de manera más crítica, proponer formas de mejorar.

Sospecho por lo que ha dicho que la pérdida de control que esto implica le dará bastante miedo. De mi parte:

• Descubrí que las retrospectivas son más abiertas y honestas si no asisto (!)
• debe estar preparado para que su equipo pueda decir cosas duras sobre usted
• debe escuchar lo que dice su equipo y actuar en consecuencia

Si no le gusta cómo suena esto, le sugiero que siga discutiendo sus problemas con su equipo y pídales sugerencias para mejorar. Si confías en ellos, responderán de manera positiva.

Una hoja de tiempo no es una forma de realizar un seguimiento del progreso. En los lugares donde he trabajado, se requería la hoja de tiempo para asignar horas al cliente adecuado. Nunca siguió el progreso de la tarea.

En realidad lo retiro. Una empresa intentó rastrear información más detallada. Tuvimos que actualizar una base de datos de Access a través de una GUI especial para designar en incrementos de un minuto el tiempo dedicado a revisar los requisitos, investigar, diseñar, codificar, construir, probar y depurar. También teníamos que contabilizar el tiempo dedicado a reuniones y tareas indirectas. Esto fue para que pudieran intentar hacer mejores estimaciones. Nunca les permitió saber día a día qué tan bien estábamos trabajando o qué tan cerca estábamos de terminar la tarea.

El hecho de no completar una tarjeta de tiempo simple no está relacionado con ser un desarrollador. Sólo viene de la comprensión de que se requiere. Si es un contratista del gobierno de los EE. UU., es obligatorio. Pueden hacer comprobaciones de tarjetas de tiempo bajo demanda. La mayoría de las empresas ahora han configurado sistemas automatizados que envían correos electrónicos cuando no se completan antes de la medianoche de cada día.

El porcentaje completado siempre va a ser problemático. A menos que las tareas se realicen en pequeñas porciones que se puedan realizar en menos de un día, las estimaciones serán incorrectas. Si la tarea tomará varios días, tenderán a querer comprometerse con porcentajes solo cuando se les obligue.

Está rebotando entre muy poco control y demasiado control. Los requisitos de la hoja de horas diarias que desea son muy estrictos, pero luego les permite comenzar tareas sin su estimación. Está tomando partes incompatibles de diferentes metodologías de gestión y preguntándose por qué no encajan.

He eliminado por completo el tiempo de seguimiento dedicado a los problemas por parte de los equipos que dirijo. No requiere reflexión por parte del individuo y no da información real sobre el estado de desarrollo. En cambio, les pido que actualicen periódicamente cuánto tiempo les queda a cada problema. Encuentro que es más fácil convencer a la gente para que haga esto, ya que hay un propósito más claro y se percibe como menos seguimiento de las personas y más seguimiento de los esfuerzos.

También cuestiono su afirmación de que no es un "PHB". Usted administra 10 desarrolladores, pero todavía realiza asignaciones de problemas individuales para todos los desarrolladores. Eso me parece tal vez demasiada microgestión. Consideraría tratar de dejar que los desarrolladores elijan sus problemas y los organicen entre ellos. Mi experiencia es que un desarrollador se sentirá más dueño de un problema si él o ella lo escogió en lugar de que se lo asignen. Trate de hacer estimaciones en una sesión de planificación grupal, en lugar de dejarlas en manos de individuos, como lo está haciendo hoy. Una vez más, según mi experiencia, eso generará estimaciones más precisas y con menos desviación a lo largo del tiempo. También fortalecerá la sensación de que está cumpliendo como un equipo en lugar de un grupo de personas en un organigrama.

No olvides realizar retrospectivas después de cada sprint. Como dices, a menudo no consigues tus objetivos. Explora por qué es así. Desafía a tu equipo a identificar las razones por las que fallas y sugiere formas de superarlas. Tu equipo no es una caja negra, necesitan decirte por qué están fallando. Y luego usted (como gerente) debe hacer lo necesario para ayudarlos a tener éxito.

Parece que estás haciendo algunas cosas ágiles, pero no todas. Agile permite flexibilidad en la forma en que administra sus equipos, pero hay cosas que simplemente deben suceder en Agile, sin importar cómo las haga, y hay una pelota que es crítica para Agile que está dejando caer; retroalimentación rápida.

Quieres el stand-up diario. Todos se reúnen en un círculo alrededor de un gráfico de quemado y les cuentan a los demás lo que han hecho desde la última reunión. Esto es algo bueno para todos; los desarrolladores obtienen una sensación diaria de logro y usted obtiene datos diarios sobre lo que está programado y lo que no. Si es necesario hacer ajustes, aquí es donde lo aprende.

Ahora, en este standup, como gerente de proyecto, usted no es un participante activo. Eres una gallina". Los desarrolladores y cualquier analista comercial o personal de control de calidad que tenga son "cerdos". La analogía proviene de un chiste:

Un cerdo y un pollo caminan por el camino. El pollo dice: "¡Oye, cerdo, estaba pensando que deberíamos abrir un restaurante!". Pig responde: "Hm, tal vez, ¿cómo lo llamaríamos?". El pollo responde: "¿Qué tal 'jamón y huevos'?". El Cerdo piensa por un momento y dice: "No, gracias. Yo estaría comprometido, ¡pero tú solo estarías involucrado!"

El resultado es que usted está "involucrado" en el proceso, pero los miembros del equipo son los que están "comprometidos" con la entrega del trabajo. El standup es su herramienta para asegurarse de que puedan cumplir y, como tal, lo ejecutan ellos, no usted. Su único requisito es asegurarse de que lo tengan y, si es necesario, asegurarse de que no se disuelva en una gran discusión (las reuniones de pie deben tomar de 5 a 10 minutos como máximo). Este puede ser un concepto difícil para un gerente, pero parece estar en el paradigma de los equipos autogestionados, por lo que espero que sea una transición más fácil.

Otros consejos:

• Hacer la estimación del proyecto durante una reunión de todos los desarrolladores. Esta reunión de estimación y planificación del sprint es fundamental, y hacerlo corporativamente asegura que todas las estimaciones lleguen; la persona está ahí, y deberías pedir estimaciones de pequeños fragmentos con un alcance bien definido; a un desarrollador nunca se le debe asignar una "epopeya" (proyecto grande y complejo) sin que primero se divida en partes más pequeñas. ¿Cómo te comes un elefante? Un bocado a la vez.
• No importa cuánto tiempo pasen (a menos que trabajen jornadas de 12 horas o de 3 horas); lo que importa es cuánto hacen cada día y si eso los encamina para cumplir con sus obligaciones. Si, después de trabajar dos días de 8 horas, están en camino de perder su estimación inicial a la mitad, entonces está sucediendo una de dos cosas; mordieron más de lo que podían masticar, o están holgazaneando y no haciendo el trabajo. Vuelva a evaluar la carga de trabajo para el sprint y, si aún parece factible, manténgalos firmes.
• Por lo general, es mejor tener equipos que trabajen cada uno en un proyecto. Un equipo no debe estar compuesto por una persona que trabaje en el proyecto A y otra que trabaje en el proyecto B. Incluso si A y B son subproyectos del superproyecto C, los equipos empujados en diferentes direcciones eventualmente se fracturarán. Los equipos pueden ser tan pequeños como una persona y, en general, funcionan bien hasta una docena (después de eso, generalmente es bueno dividir los equipos grandes en equipos más pequeños).

En tu larga lista de quejas no te vi decir que no cumplen con sus tareas. Los desarrolladores pueden quedarse atascados girando sus ruedas a veces, por lo que desea cierto nivel de supervisión.

Supervise al equipo de una manera que sea conveniente para ellos . Hay más de ellos que usted, por lo que es más importante que la comunicación sea fácil para ellos.

¿Cómo pueden comunicar su progreso? Standups, informes diarios, informes semanales, hojas de tiempo (debe tener una sección de notas para la comunicación fuera de banda): elija el que sea más conveniente para los miembros de su equipo

Veo un par de problemas.

La primera es que parece que las "tareas" que tiene son demasiado grandes. Divídalos en partes más pequeñas, preferiblemente aquellas que deben completarse en un solo día.

A continuación, no les pidas que controlen el tiempo que dedican a las tareas. Lo hace si las tareas se dividen según las expectativas diarias, esto debería ser fácil para usted y el progreso debe informarse en una reunión diaria. En su mayor parte, estoy de acuerdo con Amy y HLGEM acerca de los autoinformes de los empleados; sin embargo, primero debemos llegar a ese punto.

Lo principal que busco aquí es que si el equipo no puede estimar adecuadamente las tareas que duran más de un día, entonces debemos capacitarlos. La mejor manera de llegar allí es hacer que estimen tareas pequeñas. Un beneficio secundario es que la gente se entusiasme por mostrar el progreso. Otra es que si tiene personas que repetidamente no pueden completar tareas fáciles en un solo día, entonces sabe a quién reemplazar. Por cierto, "creativo" no significa "cuando lo hagan"

Una vez que pueda completar tareas pequeñas rápidamente, comience a pasar a tareas de varios días. En este punto, deberían poder proporcionar estimaciones mucho mejores que usted pueda mantener.

Hay más, pero creo que ahí es donde debes comenzar.