Cursos Empresas Blog Live Conf Precios

Estructura de un equipo ágil

Clase 5 de 27 • Curso de Gestión de Equipos Ágiles

Clase anteriorSiguiente clase

Estructura de un equipo ágil

DOUGLAS OSMAR CALDERON MENDOZA

student•

ESTRUCTURA DE UN EQUIPO ÁGIL

- Pequeños: de 3 a 8 personas, recomendable 5. **- Multifuncionales: **en el grupo debe de existir al menos dos personas capaces de cumplir con esa responsabilidad - Autónomos: la capacidad de toma de decisiones, sea independiente de cualquier superior en la organización y/o procesos burocráticos - Autoorganizados: definen como hacer su trabajo, no dependen de un tercero. **- Enfocados: **Concentrados en la construcción de un producto, las personas están 100% dedicadas en un único trabajo - Estables: No se están intercambiando personas entre equipos. - Coubicados: estar cerca entre si, para facilitar la comunicación cara a cara - Entregan valor temprano y frecuentemente: debe permitir todas las características necesarias para que ellos puedan entregar valor de manera temprana.

Felipe Bernardo González Barranco

student•

Gracias!

Joaquín Escalona Mella

student•

Muchísimas gracias por tu aporte

Andrés Corral

student•

Un catálogo de patrones para Scrum y agildad https://www.javiergarzas.com/2013/07/patrones-para-scrum-y-agildad.html

Felipe Bernardo González Barranco

student•

Gracias!

Nancy Quintanilla

student•

Elias De Vargas Cuéter

student•

En la unidad donde trabajo se suelen usar los mismos desarrolladores para varios proyectos, ¿cómo podría gestionarse el equipo ágil en esas circunstancias?. Pd. Dejar desarrolladores en solo proyecto no parece algo aceptable de momento :S

Andrés Felipe Salcedo Sepúlveda

teacher•

Entiendo tu situación, me pasa muchas veces que parece poco productivo dedicar a un equipo a un solo proyecto/producto, lo interesante es que al final esta forma de gestionar solo genera desperdicios.

Lograr un cambio en la forma de pensar de las personas que gestionan equipos es un tema de elevar consciencia. También es normal que esto suceda porque es la forma tradicional de gestión de equipos que traemos desde la revolución industrial, no podemos esperar que los cambios ocurran de la noche a la mañana.

Mi recomendación según mi experiencia, es gestionar este cambio cultural con agilidad, es decir, diseñando pequeños experimentos que permitan ganar cada vez más agilidad, no forzar las cosas sino buscar por donde pueden iniciar sin que haya tanta resistencia y en la medida en la que se consigan esas pequeñas victorias se ganarán aliados en el camino que ayuden a impulsar el movimiento.

Miguel Angel Camacho

student•

Es un buen ejemplo de una mala práctica. ese equipo pierde el foco en la meta del sprint.

Julian Barrera

student•

cuando se habla de autoorganizados, cuál es el alcance de decisión de un equipo con respecto a decisiones estratégicas?, porque supongo que sí es estratégico la última decisión la tiene el cliente

Andrés Felipe Salcedo Sepúlveda

teacher•

La autoorganización del equipo esta más relacionada respecto a la forma en como abordarán la solución. Desde el cliente se plantea la necesidad, es decir, "Lo que hay que hacer". El equipo autoorganizado plantea "cómo lo va a hacer".

Oscar Moreno

student•

una duda: como se podría implementar esta metodología en una institución pública en la que deben evaluar varios proyectos que requieren alta complejidad y multidisciplinariedad en el mismo periodo, ¿Se recomienda trabajar de forma serial o en paralelo?

Andrés Felipe Salcedo Sepúlveda

teacher•

Algo que debemos aprender en la gestión de proyectos o productos, es que la capacidad de construcción siempre tiene un límite, por lo que siempre será necesario priorizar y concentrar los esfuerzos en atender lo que más valor genere a la organización. Trabajar en paralelo es menos productivo porque las personas al cambiar de contexto necesitan tiempo para entender y alcanzar un rendimiento óptimo.

Por lo anterior, mi recomendación es priorizar y trabajar las iniciativas en serial, empezando por la que mas valor genere.

Yeins Richard Balaguera Rigaud

student•

Para los 5 equipos de trabajo se incluye al SM y PO? o solo seria 5 respecto al Development Teams? Gracias!

Andrés Felipe Salcedo Sepúlveda

teacher•

Muy buena pregunta Yeins Richard. El número recomendado es de 5 personas haciendo referencia solo al equipo que construye el incremento del producto. En el caso de un equipo Scrum se recomienda entonces que sean 5 integrantes en el Development Team.

Hernán Valenzuela Valenzuela

student•

¿Los equipos nuevos pueden ser autoorganizados? ¿cuanto tiempo requiere a que suceda esto si llevan menos de un año en la empresa?

Estefany Minerva Camarena Gordillo

student•

Todos los equipos pueden ser auto-organizados. Algo importante para lograr la auto-organización es que todos tengan el mismo objetivo y que estén motivados :). Teniendo estas dos cosas en mente y tratando de cultivarlas en nuestro equipo podremos lograr que sean auto-organizados. El tiempo es muy variado, hay muchos factores que influyen, entre ellos esta la personalidad de cada uno. Pero nada es imposible!!!!!

Giovanna Sanchez Leon

student•

Uno de los patrones que me parece más pertinente y que no se menciona es el de "KPIs colaborativos", donde haya una conexión de los colaboradores con la meta alcanzar

Juan Esteban Sanchez Cifuentes

student•

Andrés ¿Cuando las empresas crecen entonces lo ideal es que mantenga su estructura con equipos pequeños de 5 personas en promedio?

Andrés Felipe Salcedo Sepúlveda

teacher•

Siempre y cuando la organización quiera ser ágil… depende mucho de la estrategia, algunas empresas prefieren trabajar productos muy específicos desde la agilidad.

Julián Darío Bermúdez Trujillo

student•

¿Aunque mencionas el enfoque de los participantes de un equipo, cómo debería ser la participación de roles que seguramente deben estar rotando por varios proyectos? Por ejemplo un diseñador gráfico? ¿En el caso de los testers, deberían estar igualmente en un solo proyecto?

Andrés Felipe Salcedo Sepúlveda

teacher•

Excelente pregunta Julian, si la especialidad o habilidad del rol se requiere frecuentemente en el equipo (como puede ser el de tester en un equipo de desarrollo de software) lo mejor es que pertenezca tiempo completo en el equipo. Si se requiere muy de vez en cuando, podría ser un rol que aporte en el momento que se necesita y abandone al equipo cuando su trabajo esté terminado, o también desarrollar esa habilidad dentro del equipo fijo.

Muchas veces se piensa que tener todas las especialidades en el equipo es un desperdicio porque no necesariamente todo el tiempo estamos haciendo pruebas (utilizando el ejemplo del tester), lo que sucede es que el tester no debería quedarse mirando el techo esperando a que llegue su momento de probar, este debe aportar al equipo en donde se requiere asi no sea su especialidad, y si no sabe, aprende.

William Bustamante

student•

Cual es tu recomendación para una empresa donde su equipo de desarrollo se limita a 2?, se puede aplicar agilidad?

Giuseppe Ramirez

student•

Se puede aplicar Gestión Agile inclusive de manera personal. Así que sí es posible hacerlo para 2 personas, la comunicación es clave para evitar parecer "pesado" y más bien generar una buena cultura del team. :)

Oscar Rodrigo Leon Mojica

student•

si se puede, si lo que buscar es un marco de trabajo que te guie, te recomiendo leer sobre kanban es como scrum pero más simplificado

Oscar Cespedes

student•

Hola tengo una pregunta, en la empresa se trata de usar scrum, pero la actualidad no nos permite hacer todo, el equipo es grande es mas de 8 de hecho solo desarrollo con 16 personas y creciendo, estan por modulos. Como manejar el equipo y como sacar indicadores a los desarrolladores? lo pidieron por auditoria. Agradezco cualquier aporte

Omar Daniel Centeno

student•

Hola

Sería necesario que dividan el trabajo en equipos más pequeños, sobre todo si cada vez se integrarán más personas, de manera que cada equipo se encargue del desarrollo de diferentes módulos.

En general te recomiendo el Curso de Análisis de Datos para la Gestión de Proyectos en donde aprenderás a manejar diferentes indicadores que puedes aplicar para el control del proyecto.

La generación de indicadores específicos para desarrolladores escapa al alcance de este curso, sin embargo, podrían pedir a quienes les están haciendo la auditoría qué tipo de indicadores esperan, ya que pueden variar para cada certificación.

Algunos de los más usuales es utilizar KPI y OKR para evaluar el desempeño de cada persona.

KPIs for Software Developers: How Should You Measure Your Productivity?

Brian David Pajares Correa

student•

El equipo de desarrolladores tienen que tener por lo menos 3 personas. Siempre un líder quien haga las reuniones diarias de equipos.

Juan Esteban Sanchez Cifuentes

student•

Hola Andrés, tengo una duda, ¿Cuáles crees que deberían ser los límites de la autoorganización? ¿qué fronteras deberían esblecerse? ¿cómo sería la mejor manera de llevar esos límites a la práctica?

Andrés Felipe Salcedo Sepúlveda

teacher•

Hola Esteban que buena pregunta! Los límites de la autoorganización los debe definir el líder o quien tiene el poder de toma de decisiones estratégicas. Estos límites son particulares para cada equipo porque depende del nivel de riesgo y la competencia del equipo para hacerse cargo, estos se establecen sobre actividades. Al final se definen unos niveles de delegación para cada elemento importante.

Te explico con un ejemplo, supongamos que queremos definir los límites de un equipo sobre los siguientes temas:

Fechas de salida a vacaciones
Definición de salarios
Modificación de base de datos en ambiente productivo.

El líder puede identificar que las fechas de salida a vacaciones tiene un riesgo tan bajo y delega 100% esta responsabilidad en el equipo, por lo que para este tema no hay restricciones. Para la definición de salarios supongamos que el riesgo es mucho más alto porque puede poner en peligro la estabilidad económica de la organización, en este caso el límite podría ser que el líder es quien asume esta responsabilidad y el equipo solo puede llegar hasta compartir su opinión.

Por último la modificación de base de datos, tal vez no deba tomarse con tanta libertad como la fecha de salidas a vacaciones, pero tampoco tan dictatorial como la definición de salarios. En este caso podría definirse el límite, de que el líder debe conocer previamente cada cambio en la base de datos de producción y una vez apruebe se ejecute el cambio.

Existen diferentes escenarios donde el equipo puede tener mas o menos libertad, y a partir del riesgo, el líder debe dejar claros esos límites de hasta donde pueden llegar.

Juan Esteban Sanchez Cifuentes

student•

Ahora me ha quedado mucho más claro, ¡muchas gracias Andrés!

Luis Enrique Rodríguez Pérez

student•

ESTRUCTURA DE UN EQUIPO ÁGIL

Pequeños: de 3 a 8 personas, recomendable 5.
Multifuncionales.
Autónomos.
Auto organizados.
Enfocados.
Estables.
Coubicados.
Entregan valor temprano y frecuentemente.

Israel Gonzales

student•

Estructura de un equipo ágil

Pequeños: Entre 3 y 8 personas. Recomendable 5.
Multifuncionales: Para cada tarea, al menos 2 miembros del equipo son capaces de cumplir esa responsabilidad.
Autónomos: Autonomía a la hora de tomar decisiones importantes.
Auto organizados: Ellos mismos son los que definen como hacer su trabajo.
Enfocados: Se concentran en un único producto.
Estables: Los miembros del equipo se mantienen durante la duración de los proyectos.
Co-ubicados: Todas las personas están lo mas cerca posible entre si.
Entrega de valor temprano y frecuentemente: Deben entregar valor temprana sin depender de terceros.

Luis Elicané Tiu Paz

student•

El patrón que me llama la atención es Daily Clean Code porque es común que el cerebro no te deje dormir pensando en el código que no quedó hecho realmente o que no satisface tus criterios de calidad.

Nancy Villalobos Hernandez

student•

Una persona sin empoderamiento no tiene motivaciones para proponer mejoras, no busca hacer las cosas más eficientes, tampoco se preocupa por hacer el mejor resultado posible, solo se dedica a ejecutar tareas. El resultado es responsabilidad de quién le controla. Un trabajador empoderado podría por iniciativa propia mejorar la eficiencia de un proceso, la calidad de un entregable o incluso optimizar los tiempos de ejecución. Esta mejora podría nunca producirse si esperáramos a que sea el gerente quién la proponga, debido a que está demasiado desconectado de la situación como para apreciar la necesidad de una solución, y mucho menos para poder concebir la solución.

Daniel Carrasco

student•

Muy buen aporte, va para mis apuntes! Thks

Juan Esteban Sanchez Cifuentes

student•

¿Cuando las empresas crecen entonces lo ideal es que mantenga su estructura con equipos pequeños de 5 personas en promedio?

Andrés Felipe Salcedo Sepúlveda

teacher•

Siempre y cuando la organización quiera ser ágil... depende mucho de la estrategia, algunas empresas prefieren trabajar productos muy específicos desde la agilidad.

Juan Esteban Sanchez Cifuentes

student•

Gracias Andrés

Cristian Manuel Gonzalez Blanco

student•

Estructura de Equipos Ágiles. *Pequeños (Mínimo 5 personas) *Autónomos *Autoorganizados *CoUbicados *Entrega de valor temprana y frecuente