¿Un equipo ágil maduro requiere alguna gestión?

Después de un acalorado debate reciente sobre Scrum, me di cuenta de que mi problema es que pienso en la administración como una actividad innecesaria y redundante en un equipo totalmente ágil. Creo que un equipo ágil maduro no requiere gestión ni ningún proceso de toma de decisiones no técnico. A mis ojos (aparentemente errados) es más que obvio que el único adecuado y capaz de gestionar un equipo de desarrollo maduro es su entrenador (que es el colega más competente técnicamente con las habilidades de comunicación adecuadas). No puedo imaginar cómo un maestro Scrum puede contribuir a un equipo así.

Estoy teniendo grandes dificultades para darme cuenta y comprender el valor de tales cosas en Scrum y el gerente como alguien que no es un desarrollador veterano pero que está bien capacitado para planificar los ciclos de producción cuando existe un entrenador en el equipo. ¿Y eso que significa? ¿Cómo puede alguien sin habilidades avanzadas de desarrollo administrar un equipo altamente técnico? ¿Quizás la administración aquí significa algo más?

Veo la gestión como una pérdida total de tiempo y un subproducto de la inmadurez. En mi opinión, un equipo maduro es totalmente autogestionado. Aparentemente estoy equivocado ya que muchas personas excelentes dicen lo contrario, pero no puedo convencerme.

Estás cometiendo una serie de errores aquí.

El primero es asumir que un Scrum Master es un administrador. Ellos no están. Básicamente son un administrador-facilitador. Se aseguran de que las cosas sucedan en el horario de Scrum, pero no tienen que decirle cómo hacerlo, si es un equipo ágil completamente maduro. En su mayoría simplemente sucede.

Pero no controlan la calidad de su trabajo ni firman sus vacaciones ni nada por el estilo. Tampoco gestionan el producto o proyecto; eso lo hacen otras personas.

El error más grande que está cometiendo es asumir que puede pasar de la situación que ha descrito en otras preguntas ("Los desarrolladores están lejos de ser capaces de realizar prácticas de programación ágiles en este momento. Sin pruebas unitarias, sin programación de pares, sin CI ( ¿eh? ¿Qué es?) ... te haces una idea ") a" equipo ágil completamente maduro "de la noche a la mañana. Eso simplemente no es posible. Olvídalo. Ni siquiera lo intentes.

Si desea resultados inmediatos, busque enfoques de gestión de proyectos más estructurados. Y contratar algunos gerentes.

Si el negocio quiere que seas ágil, lleva tiempo, requiere un cambio de cultura. Y sí, al principio, cuando estás en la Etapa de mejora caótica , requerirá administración. Ya sea un individuo o un grupo, alguien tendrá que tomar algunas decisiones.

Necesita una persona o grupo que sea responsable de analizar el panorama general, explicar la situación actual tanto a los desarrolladores como a la empresa, y explicar las opciones que tiene para mejorar, averiguar qué necesita la empresa y luego guiar a las personas a través de eso.

Pasará mucho tiempo antes de que puedan llamarse un equipo ágil completamente maduro y autogestionado. La mayoría de los equipos nunca llegan allí.

En mi opinión, un equipo maduro es totalmente autogestionado.

Asumamos por un momento que tienes razón. No sé de una forma u otra, así que no lo discutamos.

El problema es que incluso un equipo autogestionado termina con alguien con buenas habilidades sociales y políticas que pueden representar al equipo en otros departamentos. Alguien que realiza un seguimiento de lo que todos están haciendo, cuando se van de vacaciones, etc. Alguien que maneja las mentiras y los presupuestos de recursos humanos. Alguien que discute con los grupos de QA y PM para que el resto del equipo no tenga que hacerlo. Alguien que media las inevitables disputas interpersonales entre los desarrolladores. Alguien para programar reuniones y mantener la moral alta.

Esta persona es un gerente.

• Llegas a casa un día y pagas el cheque no ...
• Quiere despedirse, pero el equipo está demasiado ocupado y lo ha estado durante un año ...
• Su esposa o hijo está enfermo y necesita que reduzca a 20 horas a la semana
  durante 6 meses.
• El departamento de finanzas ha pedido un recorte de presupuesto y alguien tiene que irse.
• La cafetera se rompió y nadie puede arreglarla.
• Su equipo es tan bueno que no hay defectos que corregir ni funciones que agregar, se ha quedado sin trabajo: qué hacer ahora.
• El cliente no pagará por el trabajo realizado.
• El cliente quiere más trabajo del que puede lograr y está preparado para pagarlo.

No veo nada en esta lista que no me haya sucedido en mi carrera. No veo nada en esta lista que necesite resolver habilidades altamente técnicas. Veo muchas cosas en esta lista que necesitan habilidades específicas que, francamente, la mayoría de los desarrolladores no tienen, y los buenos gerentes sí, sin importar lo que hayan manejado en el pasado.

Deje de gerentes de embolsado: reconozca que tiene un conjunto de habilidades y que tienen un conjunto diferente. Todas estas habilidades son necesarias en cualquier organización. Harás su trabajo tan bien como ellos harán el tuyo. Es raro tener a alguien bueno en ambos trabajos, es más raro tener a alguien bueno en ambos que pueda hacer ambas cosas simultáneamente. Lo que sucede sin un pesebre es que las cosas se erosionan lentamente en un estado de disfunción. Si tiene suerte, se reconoce con suficiente anticipación, se contrata a un gerente y, de repente, los problemas desaparecen como por arte de magia, y usted tiene que seguir con el trabajo que le pagan en lugar de jugar una tonta política de oficina (hablando de experiencia aquí).

Veo la gestión como una pérdida total de tiempo y un subproducto de la inmadurez.

Guau. No has trabajado con buenos gerentes últimamente, ¿verdad? (Todos hemos trabajado con los malos).

He visto a personas ocasionalmente cometer el error de asumir que algo que no entienden completamente es fácil.

(Los empresarios son especialmente culpables de esto: ¿alguna vez ha recibido especificaciones de baja calidad Y una fecha límite establecida en piedra?)

En la mayoría de las empresas, el equipo de desarrollo existe como parte de un todo más amplio. Los gerentes existen como una interfaz entre el equipo y el resto de la empresa. Un buen gerente trabajará esa relación en ambas direcciones, asegurando que el equipo obtenga lo que necesita (requisitos, espacio de oficina, computadoras nuevas, reconocimiento, bonificaciones, etc.) y comunicará las prioridades (siempre cambiantes) que salen de la oficina de la esquina. .

La oficina de la esquina existe por muchas razones, la mayoría de las cuales no son relevantes para esta publicación.

Recuerde que la mayoría de los gerentes están tomando las mejores decisiones que pueden con la información disponible para ellos, que puede no ser la misma que la información disponible para usted .

Si tuviera un equipo de desarrollo completamente maduro que formara parte de una compañía completamente madura que tuviera clientes completamente maduros y nada cambiara, posiblemente podría eliminar la necesidad de la mayoría de la administración. El término para eso es utopía .

Buena suerte con eso.

ps - lee No te llames programador : excelentes consejos y explica mejor que yo cómo nos ve el resto del mundo de los negocios.

El trabajo de un scrum master o un gerente en general no es actuar como un señor dictatorial. El trabajo de un gerente es asegurarse de que su equipo esté preparado para el éxito dentro del negocio. Eso incluye contratar a las personas adecuadas, obtener el equipo adecuado y mantener una visión estratégica del producto. Un gerente debe ser como un juez de línea, evitando que los detalles y las minucias que no son importantes para el éxito de un equipo interfieran con su progreso.

Parte del problema es que "Scrum Master" es posiblemente el papel con el título menos preciso en toda la historia. "Scrum Facilitator" sería un poco más preciso, pero como alguien más señaló anteriormente, el trabajo de SM no es administrar el equipo, sino hacer que los problemas desaparezcan para que el equipo (autogestionado) pueda continuar con sus trabajos. Sí, el scrum master también es responsable de asegurarse de que el scrum ocurra: las tareas se actualizan con las horas restantes, se mantienen en pie y agregan valor, se actualizan las quemaduras y se rastrea la velocidad, etc., pero eso sigue siendo un entrenamiento y función facilitadora, no una función de gestión.

Otra parte del problema es que la gente de las oficinas de la esquina quiere saber las respuestas a preguntas como "¿cuándo puedo enviar el software?" y "¿qué características contendrá?" y están acostumbrados a poder hacerle preguntas a un "Gerente de Proyecto" y obtener respuestas respaldadas con muchos gráficos de Gantt de aspecto impresionante y poca o ninguna mención de cosas incómodas como el cono de incertidumbre.

Bajo Scrum, es factible comenzar con una lista aproximada de las características "will", "might" y "would" para cualquier fecha de envío, pero definitivamente hay un papel para alguien, probablemente el scrum master, para mantener actualizada la oficina de la esquina con los inevitables cambios en esas listas a lo largo del tiempo. Estoy tentado a pensar en esa actividad, junto con el procesamiento de los comentarios resultantes y la gestión de nuevas solicitudes de funciones como "gestión", aunque la gestión es diferente de lo que muchos, muchos Gerentes de Proyecto podrían haber hecho en el pasado.

Si cree que no se necesita administración, ¿quién realizará los siguientes trabajos organizativos, quién responderá en las siguientes situaciones?

• Se deben encontrar nuevos clientes. ¿Cómo vendes tus productos? ¿Cómo se anuncian?
• se deben comprar materiales, se deben encontrar proveedores
• Las discusiones diplomáticas con otras compañías, bancos o una oficina gubernamental deben ser dirigidas

Estoy en un equipo pequeño sin gerente y funciona. ¿Por qué? Honestamente no lo se.

Mi mejor conjetura es que se trata del tipo de persona que eres. Algunas personas "son" computadoras, por lo que necesitan un proceso de alimentación. Otras personas son "programadores" y tienen la capacidad de crear su propio mundo y estructura de la nada.

Debo crear un sistema o ser esclavizado por otro hombre; No razonaré ni compararé: mi negocio es crear. --William Blake

EDITAR en respuesta al comentario de glenatron:
es más que solo un equipo de desarrollo. Tenemos un CEO, una recepcionista que contesta el teléfono y un técnico de TI. Nos comunicamos con los clientes directamente por correo electrónico, teléfono o reuniones. Nuestro negocio principal es crear nuestro propio producto y venderlo, en lugar de buscar contratos. Pero también hay contratos.

Lo he pensado más y estas son las razones por las que creo que funciona:
1. Principalmente creamos nuestro propio producto en lugar de crear el de otra persona.
2. Tenemos una ética de trabajo consistente independientemente sin supervisión.
3. Tenemos conocimiento de dominio.
4. Suerte. Un puñado de personas que se llevan bien y trabajan bien juntas.

Alguien mencionó que la compañía Valve tampoco tiene administración. Valve crea su propio producto en lugar de crear el de otra persona. Creo que una compañía de productos se presta mejor para la autogestión. No hay riesgo de seguir un camino diferente al que el cliente espera porque usted es el cliente. En una compañía de juegos esto es especialmente cierto. Haz que tu juego sea divertido.

No puedes manejar tu camino hacia la diversión. No puedes manejar tu camino hacia la creación original del arte.