• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

stacey

El verdadero sentido de los equipos cross-funcionales

Cuando usamos Scrum, la pregunta ¿Qué significa un equipo cross-funcional está siempre presente. La respuesta es muy sencilla: un equipo cross-funcional es aquel que tiene todos los perfiles necesarios para entregar un incremento de Software terminado al final de cada Sprint.

La complejidad de entregar Software

En el artículo sobre DevOps y Scrum, uno de los puntos más importantes a favor de la integración de desarrollo y operaciones es la capacidad de hacer software que esté orientado a la puesta en producción.

Anteriormente, también hemos hablado de como Scrum es una herramienta de gestión de la complejidad. Desarrollar software es complejo. Más que construir un edificio o cualquier otro tipo de ingeniería. Al ser un proceso completamente abstracto, las posibilidades son ilimitadas. Y las limitaciones son desconocidas. Gestionar esa complejidad es una tarea complicada. Merece la pena echar un vistazo a la Matriz de Stacey para entender este punto

El ciclo de vida del software

El ciclo de vida del software normalmente conlleva cuatro o cinco pasos fundamentales: Planificar, diseñar, desarrollar, probar y poner en producción. En Scrum todos estos pasos ocurren cada Sprint y todos los Sprints. Si no somos capaces de ejecutar todos ellos en un sólo Sprint, entonces tenemos que reconocer que existe un problema organizacional. Estos son los impedimentos que un Scrum Master ayuda a una organización a eliminar. No arreglar teclados o gestionar reuniones.

Las organizaciones que usan metodologías ágiles tienen que adaptar su mapa organizacional a un método que les permita ser ágiles. Tener un Sprint de diseño, uno de desarrollo, uno de testing y uno de operaciones no es utilizar Scrum, es hacer waterfall en Sprints. No hay que confundirse. Probablemente tenga un beneficio para la organización y en muchos casos esto acorte en buena medida el ciclo de vida del desarrollo de software, pero sigue sin ser Scrum.

Decidir la duración de un Sprint

Parece aceptado que el tiempo estándar de un Sprint es de dos semanas, sin cuestionamiento. Esta ha sido la recomendación clásica de autores como Mike Cohn o Roman Pichler. Sin embargo, tenemos que ir un paso más allá y ver cuales son los dos factores fundamentales para decidir la duración del Sprint:

  1. El tiempo mínimo que necesita el equipo de desarrollo para entregar una pieza de Software terminado. Esto incluye los pasos expuestos más arriba: Planear, diseñar, desarrollar, probar y poner en producción.
  2. Un horizonte aceptable de riesgo para el Product Owner. Quizás el Product Owner no considere oportuno entregar Software más allá de dos semanas. O quizás esté bien que se tarden 30 días o menos.

La realidad es que Scrum dice: Software en 30 días o menos. No dice Sprints de dos semanas. El objetivo es tener ciclos cortos de feedback que permitan transparencia, inspección y adaptación.

Los equipos cross-funcionales son la manera de entregar software en 30 días o menos

Ahora es más fácil ver por qué los equipos cross-funcionales significan cosas distintas para empresas distintas. Mientras que para una start-up un equipo cross-funcional puede ser todo desarrolladores junto con una persona de producto, para un banco, los equipos cross-funcionales deben de incluir un business analyst, alguien de compliance, un dba, un tester y alguien de operaciones.

La única manera de preguntarnos si tenemos equipos cross-funcionales es mirar si estamos entregando software terminado cada Sprint. Si no, es un impedimento a eliminar. En muchas ocasiones, eliminar ese impedimento supone desafiar el status quo de la organización para mejorar y optimizar procesos.

Este proceso es agilidad y transformación en estado puro. Scrum es simple pero no es fácil.

Complejidad con la matriz de Stacey

La matriz de Stacey es un mapa visual para entender los distintos caminos y conceptos de los sistemas complejos y analizar la complejidad de los mismos; está basada en el trabajo de Ralph Douglas Stacey y habitualmente su representación difiere de su trabajo original sobre los sistemas adaptativos y la teoría del caos.

Como cualquier representación visual de un concepto complejo, deja muchas variables fuera, sin embargo puede servir como guía ofreciendo un método para seleccionar las acciones de management más apropiadas en un sistema complejo adaptativo basado en el grado de certeza y el nivel de acuerdo en torno al tema en cuestión.

El arte de la gestión y el liderazgo es tener una lista de técnicas y ser consciente de cuando y cómo usarlas. Ralph Stacey propuso una matriz para ayudar en esta tarea mediante la identificación de decisiones de gestión en dos dimensiones: el grado de certeza y el nivel de acuerdo.

El nivel de incertidumbre y la complejidad

Según esta matriz, el nivel de incertidumbre es un continuo sobre el que nos movemos a la hora de tratar sobre determinados temas.

Alto nivel de certidumbre: Hay temas o decisiones están más cercanas a la certeza cuando existe causalidad: es decir, se puede determinar causa y efecto. Este es normalmente el caso cuando un tema similar o una decisión sobre el tema se ha tomado anteriormente. Se puede extrapolar la experiencia para predecir el resultado de una acción con un cierto grado de certeza.

Alto nivel de incertidumbre: En el lado opuesto del continuo de la certeza existen situaciones inciertas. Estas situaciones son normalmente únicas o es la primera vez que se dan para aquellos que tienen que tomar una decisión al respecto. Las causas y efectos no están claras. Extrapolar desde la experiencia anterior no es el mejor método para predecir resultados en este rango.

El nivel de acuerdo y la complejidad

En el eje vertical se mide el nivel de acuerdo sobre un tema o decisión dentro de un grupo, equipo u organización. Como se podría esperar, la función de gestión o liderazgo varía dependiendo del nivel de acuerdo sobre un tema.

Hay un área muy amplia en este diagrama entre la región de la anarquía y las regiones de la gestión tradicional. Stacey llama a este amplio centro la zona de la complejidad -otros lo llaman la frontera del caos-. En la zona de complejidad, los enfoques de gestión tradicional no son muy efectivos, sino que es una zona que llama a la creatividad, innovación y romper con el pasado para crear nuevas formas de operar.

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad