El papel del equipo de desarrollo en la configuración de Jira

Permítanme comenzar explicando el gran problema irreparable aquí:

Se incorporó a un nuevo director de tecnología por encima de mi equipo, e insiste en decidir cómo se configura Jira, lo que afecta a las personas que no le reportan. A pesar de su insistencia en lo contrario, no parece tener la menor idea de cómo funciona Agile o Scrum, pero el resto del equipo se siente muy cómodo con estas cosas. Él no entiende lo que sucede en un standup, y cuando forzamos una retrospectiva recientemente, miró su computadora portátil el 90 por ciento del tiempo. Esto (y su aparente confusión entre cascada y ágil) está causando problemas muy reales.

Es un programador talentoso, pero también un poco idiota y un comunicador inescrutable. Lidera por mandato, no por el ejemplo. Es tan malo que ya he decidido que me iré (espero una oferta en los próximos dos días), y nuestro desarrollador front-end senior renunció justo después de que contratamos a un front-ender muy junior que realmente necesitaba su tutoría

Ahora, a mi pregunta de alcance más limitado

¿Debería alguien en este papel tener una voz importante en este tipo de cosas? La forma en que quiere configurar Jira no tiene sentido para nadie más. ¿Cómo puedo retroceder y abogar por Agile y Scrum?

Estoy tratando de arreglar esto tanto como sea posible antes de irme porque me gusta la compañía y realmente me preocupo por el equipo y quiero verlos triunfar.

Cualquier consejo sobre cómo ayudarme a ayudar a mi equipo antes de irme sería apreciado.

Hola, creo que su pregunta tiene mucho potencial, si pudiera pulirla un poco para hacer (incluso) más específico sobre "debería la administración influir en cómo el equipo va a utilizar una herramienta" o algo así
¿Qué tipo de configuración intentó cambiar el Director? ¿Fue el flujo de trabajo de la tarea o la reconfirmación de roles o algo más?

Respuestas (3)

Apunte a la(s) meta(s), no al camino.

Jira es una herramienta como cualquier otra. Con demasiada frecuencia veo personas preocupadas por mantener a Jira organizado, olvidando que, como cualquier otra herramienta, Jira debe ser un medio para lograr un objetivo o resultado adecuado.

Da un paso atrás: piensa ¿por qué estás usando Jira ? Enumere las 3 razones principales. Como él (o incluso mejor, todos los que usan Jira si quieres tener una vista más consistente). ¿Son iguales las respuestas? ¿Los objetivos del uso de Jira son los mismos? Tal vez su gerente esté solicitando un uso específico porque prevé algunos informes específicos que no se pueden obtener utilizando Jira tal como está. Tal vez tiene una vista orientada a la cascada y espera tener Fechas de vencimiento de Jira. La conclusión aquí es que, si hay un conflicto sobre el uso de Jira, es porque las personas tienen diferentes expectativas sobre Jira. Cuando hables sobre ello, trata de evitar nombrar a Jira en absoluto.

Ejemplos:

  • como desarrollador, necesito saber cuáles son los trabajos de máxima prioridad que tenemos
  • como desarrollador necesito saber cuantas actividades tengo dependiendo de mi
  • como gerente, necesito saber cuánto trabajo acumuló (sí, evité usar la palabra 'atraso' a propósito) mi equipo tiene
  • como gerente, necesito saber a dónde va la mayor parte del esfuerzo del equipo
  • como gerente, necesito saber cuánto trabajo entregaremos el próximo año (alerta de spoiler: a menos que su empresa sea muy madura, Jira no responderá eso).
  • como usuario, necesito saber cuándo se completará mi solicitud
  • como probador, necesito conocer a los desarrolladores con los que debo hablar cuando surjan preguntas

Ahora, configure el plan para alcanzar los objetivos: siempre que todos estén en sintonía sobre lo que Jira puede (y lo que es más importante, ¡ no puede !), proponga algunos planes sobre cómo alcanzar los objetivos. Si hay conflictos en los objetivos, es necesario establecer prioridades (y discutir alternativas). Digamos que, si el gerente necesita saber el plan de entrega de 1 año, decir "Jira no lo tendrá, aguanta" no ayudará. Las alternativas deben ser discutidas. Del mismo modo, si el enfoque acordado no ayuda al equipo, el equipo debe acordar cómo abordar los objetivos (hasta tener 'capas' de uso de Jira, por ejemplo... por ejemplo, los gerentes usan Epics como quieren y el equipo usando Tarea / Historias).

Para su primera pregunta: JIRA es un sustituto del tablero de tareas, que es una herramienta para que el equipo visualice y organice su trabajo y para que las partes interesadas vean rápidamente cómo progresan las cosas. En su mayor parte, eso significa que le corresponde al equipo decidir cómo se usa. La gran excepción que vería a esto sería que no es descabellado que una parte interesada haga una solicitud sobre la configuración para que obtenga una mejor visibilidad del estado del sprint y el trabajo si no impacta al equipo también. mucho.

Para su segunda pregunta, esa es difícil. Realmente se reduce a por qué lo están haciendo. Para muchas personas, la intención es buena: creen que están ayudando. Tal vez lo que están haciendo funcionó en otro lugar y asumen que funcionará allí. O, tal vez él realmente tiene una mejor manera de hacer las cosas, pero como él solo lo está forzando, obtienes toda la interrupción del cambio, pero no puedes ver ningún beneficio. Para estas personas, por lo general, puede mostrarles el impacto que están teniendo y pedirles que reduzcan la velocidad y realicen algunos cambios experimentales con el equipo, pidiéndoles que ofrezcan sugerencias sobre los problemas con los que el equipo está luchando y puede probar esas sugerencias antes de hacer ellos permanentes. Los cambios que realmente son mejores tendrán sentido y los cambios que no encajen quedarán en el camino.

En raras ocasiones, me encuentro con personas que hacen esto sin buenas intenciones. De alguna manera han aprendido a lo largo de su carrera que deben controlar las acciones de otras personas y así es como saben que son un líder importante. Estas personas pueden cambiar, pero es un largo camino. Por lo general, es más fácil simplemente salir de su área de daño.

+1 De acuerdo en que las personas nuevas rara vez son malas personas: si tienen malas ideas, entonces puede ser más simple quitarse del camino, ya sea que eso requiera o no dejar la empresa es una cuestión diferente

El punto simple a recordar es que si te vas, lo mejor que puedes hacer por tu equipo es casi con seguridad nada . Al tratar de 'arreglar' las cosas, todo lo que puede lograr es molestar a sus colegas a quienes no les gusta el conflicto implícito que surgirá.

Estoy tratando de arreglar esto tanto como sea posible antes de irme porque me gusta la compañía y realmente me preocupo por el equipo y quiero verlos triunfar.

La gente nueva rara vez hace cosas por algún tipo de disfrute del mal de los villanos de Hollywood. Tal vez el nuevo director de tecnología haya sido promovido fuera de su zona de confort, tal vez haya exagerado su experiencia. No importa, sigues adelante.

Concéntrese en asegurarse de que sus tareas estén completas y que sus proyectos funcionen sin problemas cuando se vaya . Así es como puede servir mejor a su equipo.