¿Qué podemos hacer por un equipo fragmentado con proyectos cortos?

Estoy trabajando en una agencia y somos siete empleados. La mayoría de los empleados tienen habilidades muy específicas. Hay un empleado para producción de video, dos para diseño, uno para redes sociales, uno para sitios web, uno para administración general y yo para aplicaciones web. Dos de ellos son jefes.

Debido a esas diferentes habilidades, cada persona no puede ser reemplazada por otra. Trabajamos principalmente solos en nuestros proyectos, pero a veces necesitamos a otros. Somos muy autónomos en nuestro trabajo y nos manejamos solos la mayor parte del tiempo.

Buscamos herramientas para tener una visión más clara de nuestros proyectos. Queremos saber si alguien está ocupado o no y cuándo se realizará la tarea que asignamos a otros. También tenemos que ver cuando las cosas van mal.

Estoy leyendo sobre Kanban y Scrum. Parecen estar enfocados en equipos más grandes y proyectos más grandes.

¿Qué podemos hacer por nosotros, con un equipo fragmentado con proyectos cortos?

EDITAR 19/07/2016

Planeo hacer dos cosas. Primero, quiero agregar un tablero con dos columnas. La primera columna es para problemas. Un miembro del equipo puede agregar un título para un problema y su nombre entre paréntesis. Otras personas con el mismo problema agregarán su nombre entre paréntesis para que sepamos si es un problema personal o un problema de equipo. La segunda columna es para ideas de soluciones. Las ideas pueden estar relacionadas con un problema. Una vez a la semana, tendremos una reunión para hablar sobre los problemas que vivimos y tratar de encontrar soluciones.

El segundo tablero se dividió así:

| Recurring | To Do | In progress | in validation | done | waiting Design | | | | | | | Video | | | | | | | Dev Web | | | | | | |

Recurrente es para tareas que tenemos que hacer todos los días, semanas, meses... esperando es para tareas que tenemos que esperar por un evento externo. Otras columnas son autoexplícitas.

Una tarea debe tener un título, una prioridad y una velocidad. La prioridad la establece la persona que agrega una tarea y la velocidad debe establecerla la persona a cargo. Planeo dar una cantidad de imanes (3 o 4) y pueden colocarlos en las tareas en las que están trabajando. Si quieren trabajar en otra cosa y no tienen imanes libres, tienen que hacer una tarea antes para empezar otra.

¿Qué piensas? No estoy seguro acerca de la columna "To Do" porque una tarea sin un imán es una tarea para hacer. Tal vez pueda encontrar mejores columnas.

Tan pronto como lo averigüe, te lo haré saber. He estado luchando con una situación similar por un tiempo ahora.
Estás recibiendo una serie de respuestas referentes a Scrum. Sé cauteloso. Scrum está diseñado para un solo equipo con un solo producto y un objetivo compartido. No tienes esto, lo que hace que Scrum sea algo difícil de implementar.
'Scrum está diseñado para un solo equipo con un solo producto' es falso. Además: la pregunta es en parte sobre la idoneidad de Scrum en esta situación, que se responde con las respuestas que menciona. Los votos negativos parecen un poco duros. @Dougui, su situación tiene Kanban escrito por todas partes. Lea 'Kanban y Scrum, sacando lo mejor de ambos' si aún no lo ha hecho. Está disponible gratuitamente y brinda una gran perspectiva en las prácticas diarias.
@upstream muéstrenme un solo equipo de Scrum trabajando efectivamente en múltiples productos y me comeré el sombrero.
Un tablero kanban es el camino a seguir para su situación. Básicamente kanban es scrum sin sprints. Las personas muestran en el tablero kanban en qué están trabajando, qué cosas están en espera y cuáles están completas. Los gerentes pueden intercambiar tareas, pero solo pueden asignar una cantidad fija de tareas a la vez. O en su caso, cada miembro del equipo solo se asignaría una cantidad fija de tareas. Pero le advierto que la primera regla de la administración es ¡no sea un gerente a menos que le paguen por serlo!
@RubberDuck eso sucede mucho. Además de eso, tiene varios equipos trabajando en un producto, lo que también sucede mucho. Su comentario ignora ambos, mientras que ambos están permitidos, son comunes y se pueden hacer con éxito. Cuando no lo es, depende de la gente hacer algo. No odies el marco, odia el juego.
@upstream No digo que Scrum sea malo. Estoy diciendo que tenga cuidado al considerar Scrum para esta situación particular. Puedo ver fácilmente muchos equipos/1 producto, pero tener muchos productos para un equipo es un problema de priorización .
@RubberDuck ciertamente es mucho más difícil, en eso estoy totalmente de acuerdo :)
@RubberDuck Acabo de actualizar mi pregunta con algo que planeo hacer. ¿Puedes decirme lo que piensas?
@upstream, su opinión puede ser útil en la actualización que hice.
@Dougui El plan en su edición parece un buen comienzo. Lo más importante es probar algo e inspeccionar->adaptarse regularmente. Sugerencias: Pondría la espera entre las tareas pendientes y el progreso, ya que es un flujo más natural y enfatizaría más los 'bloqueos', pero tal vez eso sea algo personal. En segundo lugar: en caso de duda, opta por el minimalismo, es decir, menos columnas. Por último: me repito, pero... lea 'Kanban y Scrum, sacando el máximo partido de ambos' si aún no lo ha hecho. ¡Buena suerte! = )

Respuestas (4)

Parece que necesita agregar una actividad periódica a su gestión llamada integración.

Una vez al día/semana/mes, deben sentarse todos juntos y determinar cuándo se necesitan, y por cuánto tiempo, y programar en consecuencia.

Un conjunto de notas adhesivas en una pared (un carril por persona) es todo lo que necesita para realizar el seguimiento.

TL;RD;

Es muy poco lo que puede hacer con la falta de enfoque y el trabajo distribuido que fomenta su modelo actual. Puede monitorear todo el trabajo en un tablero kanban e intentar mantener el flujo, pero la visibilidad es su mejor resultado.

Equipos multifuncionales

Los equipos son mucho más productivos y producen mejor calidad que los individuos aislados. Sin embargo, Scrum no exige que todos los miembros de un equipo puedan hacer todos los trabajos. Solo que cualquier equipo puede abordar todo el trabajo que asume de forma autónoma.

Única fuente de verdad

Si reúne todo el trabajo que debe realizarse en un solo trabajo pendiente y los "jefes" lo priorizan, puede hacer que un equipo interdisciplinario trabaje en esa lista y entregue primero el valor más alto posible.

Lea la Guía de Scrum ( http://scrumguides.org ) e intente promulgar los valores y principios que contiene.

Scrum te ofrece el standup diario. Este es el momento de discutir:

si alguien está ocupado o no y cuándo se realizará la tarea que asignemos a otros. También tenemos que ver cuando las cosas van mal.

Por supuesto, cualquier persona en cualquier momento conveniente puede ponerse en contacto con un miembro del equipo de desarrollo. O en términos de la guía oficial de Scrum:

Los usuarios de Scrum deben inspeccionar con frecuencia los artefactos de Scrum y avanzar hacia un Sprint Goal para detectar variaciones no deseadas. Su inspección no debe ser tan frecuente que la inspección se interponga en el camino del trabajo. Las inspecciones son más beneficiosas cuando las realizan diligentemente inspectores capacitados en el lugar de trabajo.

En una nota al margen: es posible que desee trabajar para hacer que el equipo sea un poco más multidisciplinario. Es probable que haya cierta superposición en las habilidades de los miembros del equipo, o áreas donde esto se puede crear. Por ejemplo: probar el trabajo de un miembro del equipo, manejar la documentación o la comunicación, las personas de diseño aprenden más sobre video y redes sociales y viceversa, el sitio web y la aplicación web aprenden más sobre los proyectos de los demás. La experiencia es muy difícil de transferir, pero algunos pequeños pasos pueden hacer mucho para quitarle la peor parte al factor bus .

Finalmente: si está buscando en Scrum y Kanban, y tiene dificultades para hacer que Scrum haga clic, comience con Kanban. Tiene muy pocas reglas y te da mucha libertad, al mismo tiempo que permite que el equipo rastree e inspeccione cómo 'fluye' tu trabajo.

Al principio, usted, quise decir equipo, debe realizar un seguimiento de todas sus tareas durante todos sus proyectos. Le ayuda a saber acerca de su disponibilidad. Por supuesto, puede intentar usar el tablero Kanban o algo así, pero debe elegir su propia forma de hacerlo. En segundo lugar, para reducir el tiempo de planificación, puede realizar un seguimiento de las tareas durante una sola iteración, como se dijo en el comentario anterior. En tercer lugar, sobre fallas en el seguimiento. Debido a un equipo pequeño, puede calcular su velocidad muy rápidamente. Además, debe tener en cuenta su tiempo adicional para corregir errores.

La reunión periódica es una parte de SCRUM. Y realmente te ayuda a trabajar de manera más eficiente. En estas reuniones, puede discutir sus problemas, programar ayuda en otro proyecto, etc.