¿Hay correspondencia entre documentos a reportar a la PMO de proyectos en cascada y proyectos con Scrum?

La oficina de proyectos - cortesía de Tamer

Recientemente un jefe de proyecto que estuvo en uno de mis cursos de Scrum me escribió contándome que ya estaba aplicando el marco, pero que la oficina de proyectos le demanda los documentos más habituales de un proyecto en cascada, y me pidió asesoramiento sobre cuál podría ser una correspondencia de los mismos en Agile-Scrum.

No hay correspondencias, una oficina de proyectos ágil tienes las funciones de:

• Asignar y asegurar la financiación en base a la estrategia de la compañía
• Guiar, asistir y apoyar la ejecución de los proyectos
• Tomar métricas de productividad en términos de valor de negocio, satisfacción de cliente, salud en las relaciones con los partners, motivación del personal y presentación de informes que den valor a la compañía como calidad, nivel de Agilidad y time-to-market

y el cuadro de artefactos clásico sobre el que mi pidió asesoramiento tiene este aspecto:

Bien, fijémonos que el cuadro trata puntos de control que son de proceso, no de productividad sobre el valor como sería en el caso de Agilidad.

Hace más ruido un árbol que cae que todo un bosque que crece

(Oscar Andrés Rodriguez)

Hice el ejercicio por curiosidad y diversión, y busqué correspondencias aunque fuera como comparar naranjas con cebollas.

C1 Stage Gate

Project Charter with Tier determination
Correspondería a un plan de proyecto con determinación de nivel; lo más cercano a un plan de proyecto serían las actividades de la incepción ágil en la que se crea la visión, se identifica a la comunidad de comprometidos e interesados, se muestra a muy grandes rasgos la solución y se estima de forma preeliminar su tamaño.

(Draft) Business Case
Correspondería a la exploración del modelo de negocio mediante un Business Model Canvas.

High level timeline
Correspondería a la hoja de ruta de la planificación ágil, en caso correspondería a la hoja inicial que debería de ajustarse con cada en entrega a mercado o producción.

Cost estimates +/- 50
Podríamos asociarlo a una de las actividades de la incepción ágil, al ¿Cuánto cuesta? que es una estimación de costes muy a grandes números que sirve para situarnos en el orden de magnitud.

C2 Stage Gate

Completed requirements matrix/document
Correspondería a la pila de producto inicial a nivel de epics obtenida en un User Story Mapping.

Approved Business case
Correspondería al Business Model Canvas aprobado, pero ojo, en Agilidad hasta que no obtengamos feedback del mercado no habremos madurado lo suficiente... a medida que entregamos y obtenemos feedback del mercado deberemos de seguir explorando con el canvas.

Detailed Project Plan and sign-off
Correspondería a un documento que recogiera el plan del proyecto, quizá como lo propone SAFe con un lightweight epic-only business case.

Timeline
Correspondería a la planificación de release, que también está viva y se iria actualizando con cada sprint entregado.

Resource Plan
Para Scrum utilizaríamos el sprint 0 para aseguramos que todos los recursos están disponibles. Los riesgos se mitigan rápidamente en Scrum, el sprint 1 fallará si algo no está disponible ya que entregamos de forma temprana algo totalmente funcionando y potencialmente instalable en producción.

Vendor Management Plan
En Scrum se trata de trabajar de forma cotidiana y cara a cara a lo largo de todo el proyecto. Para trabajar en Scrum no debe de haber diferencias entre el personal del cliente y el del proveedor, realmente se trata de partners, y absolutamente todos los integrantes del equipo global deben de estar comprometidos con el proyecto.

Cost estimates +/- 10%
El enfoque de la Agilidad es distinto; la compañía decide desde la estrategia el presupuesto a invertir en el producto y confía en sus equipos de negocio, representados por sus Propietarios del Producto, para darles el poder de decisión para invertir en todo momento en las funcionalidades que más valor de negocio tengan. El proyecto se acaba cuando el presupuesto se acaba, pero garantizando que con el presupuesto asignando se ha invertido de la mejor forma posible y se ha construido el mejor producto posible.

Implementation Gate

Test Plan
Se acomete sprint a sprint, cada sprint debería de incluir el testing hecho al 100%, aunque podemos seguir un patrón semi-ágil para ser más clásicos y estar alineados con la oficina de proyectos. :-P

IT testing sign-off
Podríamos asociarlo a lo que ocurre en la revisión de sprint cuando repasamos todos los criterios de aceptación. En un entorno con pruebas automatizadas ocurre cuando todos los indicadores están de color verde.

Performance testing sign-off
Se deberían de hacer a los largo de los sprints o antes de subidas a producción por el equipo de testing de sistemas.

UAT sign-off
Se deberían de hacer por parte del usuario o equipo de negocio después de cada sprint entregado.

Training plan
Debería de ocurrir con cada subida a producción, recodemos que en Scrum practicamos la entrega frecuente con lo que la curva de aprendizaje es muy corta.

Project Delivery Gate checklist and sign-off
El equipo de gestión de entregas a producción deberá de tener su lista DoD de definición de hecho que deberá de cumplir antes de subir a producción.

Project Status prepared by Project Managers
No hay project managers, el avance real del proyecto se conoce con cada sprint entregado, recordemos el séptimo principio del Manifiesto Ágil: "El software que funciona es la principal medida del progreso". El progreso del sprint se conoce de forma diaria en las reuniones diarias y a través del gráfico de burndown.

Steering Committee organized by Project Mgr
El gobierno de la construcción del producto debería de garantizar que en cada momento se esté construyendo lo que más valor de negocio aporte, y eso es reponsabilidad de negocio, concretamente de los Propietarios del Producto, y en un marco escalado del equipo de Product Managment.

Project Financials prepared by Project Mgr & Project Sponsors
Es responsabilidad de los Propietarios del Producto conocer el valor de negocio y el ROI de cada historia de usuario y epic, métricas que se deben de actualizar con cada sprint.

Project Closeout lead and organized by Project Manager Participate lessons learned
El enfoque de la Agilidad es distinto; la forma ágil de conocer el éxito de un proyecto es hacer una encuesta de satisfacción al usuario final, identificar el nivel de "contento" del mismo con el producto resultante. Respecto a las lecciones aprendidas recordar que Scrum se basa en la mejora continua, una mejora que se produce poco a poco en cada sprint y a través de las retrospectivas. La cuestión es si tiene sentido buscar mejoras cuando el proyecto ya está acabado. Desde el punto de vista ágil lo ideal es que un producto/proyecto no tenga fin, ya que eso significa que está vivo y que produciendo beneficios para la compañía. Un producto que no evoluciona probablemente esté obsoleto.

Mis a agradecimientos Fidel que me ha instado a hacer este ejercicio... :-D

¿Cómo realizar testing a caballo entre gestión clásica y Scrum?

Un patrón de testing semi-ágil

En uno de los equipos que acompaño la especialista en pruebas, dependiente del departamento de testing de la compañía, aportó su experiencia para dar solución semi-ágil al testing en un equipo trabajando con Scrum en un entorno tradicional.

La idea es hacer las pruebas en dos momentos, pruebas de desarrollo durante el sprint y las pruebas de testing a lo largo del siguiente sprint mientras el equipo construye nuevas historias de usuario.

Las pruebas de desarrollo se realizarán al acabar cada una de las historias de usuario del sprint para asegurarnos de que todas las historias de usuario cumplen con los criterios de aceptación, y se hará una batida general al final del mismo. Estas pruebas no se recogerán ni documentarán en herramienta de pruebas alguna, quedan dentro de la "cocina" del equipo.

A lo largo del sprint se ejecutaran pruebas unitarias, funcionales y exploratorias en el entorno de desarrollo, y/o en algunos casos en alguna máquina local. Antes de la entrega de las historias de usuario, en la revisión de sprint, estas se subirán al entorno de test, recordemos que para entregar necesitaremos un entorno donde el Propietario del Producto y su equipo de negocio puedan recepcionar las historias de usuario y hacer sus pruebas de aceptación. En este momento se hará una nueva batida para asegurarnos de que también en test alcanzan los criterios de aceptación, se harán pruebas de integración y pruebas de humo para asegurarnos que todo encaja y para tener una revisión de sprint sin sorpresas.

Posteriormente a la revisión de sprint, y antes de las pruebas de aceptación de usuario y sin exceder para ambas el tiempo del sprint, se realizarán las pruebas de testing del sprint que acabamos de entregar. Estas serán pruebas más exhaustivas, más cercanas a lo que percibe el usuario, entre ellas las pruebas funcionales completas y las pruebas de regresión. Si los resultados de estas pruebas implican trabajo por parte del equipo, estas se agregan en forma de historias técnicas en la pila de producto.

También será el momento de realizar algunas pruebas no funcionales; de seguridad, de carga, de usabilidad, de rendimiento, de escalabilidad, de mantenibilidad, de portabilidad, de compatibilidad, de calidad... las que se consideren según las necesidades del proyecto.

Dada la característica semi-ágil de este patrón de pruebas es usual que las pruebas se registren en una herramienta de pruebas, como Testlink, y los posibles defectos descubiertos en un gestor de incidencias como Mantis.

La experiencia esta siendo positiva y está funcionando, pensemos que la transición hacia Agilidad puede ser un camino largo y lleno de piedras dependiendo del tamaño y de la cultura de compañía.

Mis agradecimientos a María Jesús, una Senior Software QA-Tester que compartió su experiencia con el equipo y conmigo :-)

¿Existe alguna herramienta de coaching para ayudar a crear una visión sólida de una transformación ágil?

Alexey Krivitsky presentando el Agile Coaching Canvas

En el Global Scrum Gathering Munich 2016 Alexey Krivitsky nos presentó el Agile Coaching Canvas y nos llevó por un viaje interior en que cada uno de los coaches ágiles que asistimos hicimos un viaje interior a como serían nuestra empresas cuando las hayamos llevado a la Agilidad.

Sueña el futuro,

así conseguirás llegar a tu objetivo.

Solo tu puedes hacer que tus sueños se hagan realidad,

es tu responsabilidad.

El canvas es una herramienta para ayudar a crear una visión sólida y pegadiza de una transformación ágil, aplica desde los equipos y agentes del cambio a los líderes de la compañía. El canvas está concebido para tres escenarios principales:

1. Como una herramienta individual o de auto-coaching: el lienzo puede ayudar a construir una visión de la ruta de entrenamiento para nuestros clientes, así como para los miembros de equipos de Scrum.

2. Como una herramienta de entrenamiento entre iguales: puede ser de gran ayuda durante los diálogos entre coaches ágiles / Scrum Masters para ayudarse mutuamente a obtener imágenes más claras de sus estrategias y tácticas de coaching.

3. Como una herramienta de entrenamiento del equipo: durante "futurospectivas" del equipo el lienzo puede ayudar a estos a crear de forma colaborativa una visión compartida de su futuro junto con algunas ideas sobre cómo llegar allí.

Agile Coaching Canvas y las instrucciones en el reverso que están descargables en la página del autor

La ruta del canvas empieza con el apartado del visionado (visioning) en el que nos imaginamos nuestro mayor sueño del futuro éxito. Abrimos la mente dejando de lado la situación actual, nos imaginamos como queremos que sea el futuro de la compañía, buscamos qué es lo que ha cambiado y a quienes les ha cambiado la vida.

En el siguiente paso nos situamos en dónde estamos para entender la situación actual (navigating), y así encontrar dónde poner el foco de nuestro esfuerzo y encontrar los retos por los que empezar.

Finalmente dibujaremos el camino de cómo hacer la transformación (detailing), qué aptitudes hay que desarrollar, de quienes necesitaremos ayuda y como y a quién aplicar nuestros esfuerzos de formación, coaching, facilitación y mentoring.

Es una gran herramienta, yo vi una empresa llena de luz, de tableros vivos que mostraban que se está haciendo un gran trabajo, equipos hablando seguros y motivados, gente contenta... y vi por donde empezar :-)

---

Descargas / Downloads

Co-create, capture and share with the help of the Agile Coaching Canvas, the instructions.

La versión 1.2.5 traducida que corresponde a este post.

¿Como modelar el producto desde la perspectiva del cliente?

Mapa de empatía, lo que piensa, oye, dice y siente

El objetivo último de cualquier proyecto o construcción de un producto es que nuestro cliente sea más competitivo, se
sitúe fuertemente en el mercado y por ende tenga más beneficios. Agilidad está centrada en el cliente, por tanto debemos de comprender a nuestros usuarios y sus necesidades para poder darles un mejor producto.

Quiero presentar en este post una técnica que hemos trabajado en el Global Scrum Gathering Munich 2016, el mapa de empatia, una técnica desarrollada por XPLANE y que se utiliza en Design Thinking, un conjunto de métodos que tratan de desarrollar la innovación tomando como único punto de partida a las personas que son beneficiarias del producto.

El mapa de empatía nos permite ir más allá de lo que parece que quiere el usuario o cliente, o de lo que dice que quiere. A través de la empatia hacia la persona llegamos a entender lo que realmente quiere, a comprenderla dentro del sistema de su compañía, sus rutinas, motivaciones, aspiraciones, preocupaciones, necesidades y frustraciones. Solo comprendiendo a las personas nuestra propuesta de solución puede ser guiada por valor.

El mapa permite responder de forma más acertada a preguntas como: ¿qué servicios necesita nuestro cliente?, ¿nuestra propuesta de valor soluciona algún problema real del cliente?, ¿qué aspiraciones tiene el cliente y cómo podemos ayudarle a alcanzarlas?, ¿el cliente está realmente dispuesto a pagar por esto? y ¿cómo prefiere que sea la relación y se establezca la comunicación?

¿Cómo funciona la dinámica?

Antes de nada debemos identificar quienes son los clientes objetivo en base a una serie de atributos comunes (desde demográficos hasta por cómo usan el producto) para obtener así los grupos o segmentos sobre los que focalizarnos. Los mapas de empatía tratan de personas, no de segmentos, por tanto el siguiente paso será materializar esos grupos dando vida a unas pocas personas de cada uno de ellos mediante la técnica de la User-Persona.

A partir de aquí ya podemos construir el mapa de empatía colocando de forma colaborativa respuestas escritas en post-its en las diferentes partes que componen el mapa:

¿Qué piensa (think)?

• ¿Qué es lo que le mueve?
• ¿Cuales son sus preocupaciones?
• ¿Qué es lo que le importa realmente (y qué no dice)?
• ¿Cuales son sus expectativas?

¿Qué escucha (hear)?

• ¿Qué es lo que escucha en su entorno profesional?
• ¿Qué le dicen sus amigos y familia?
• ¿Quienes son sus principales influenciadores?
• ¿A qué medios y canales atiende?
• ¿A qué tipo de ofertas está expuesto?
• ¿A qué tipo de problemas se enfrenta?

¿Qué dice (say)?

• ¿Cual es su actitud?
• ¿Cómo se comporta habitualmente en público?
• ¿Qué dice que le importa?
• ¿Con quien habla?
• ¿Influencia a alguien?
• ¿Existen diferencias entre lo que dice y lo que piensa?

¿Qué siente (feel)?

• ¿Qué lo conmueve?
• ¿Qué le quita el sueño?
• ¿Cuales son sus sueños?

Una vez obtenido el mapa hay que validarlo, salir a la calle y analizar las hipótesis sobre las que ha sido construido y comprobar si motivan al cliente o no. El mapa no es estático, hay que revalidarlo y refinarlo, e incluir cada descubrimiento que hagamos.

Preparación de un mapa mental en el taller de Design Thinking en el Global Scrum Gathering de Munich 2016

En el taller imaginamos a un supuesto futuro directivo ágil encargado de ejecutar la transformación ágil de una compañía clásica, en la que empezaría por aplicar Scrum a un primer proyecto. Estos fueron algunos de los resultados:

¿Qué piensa (think)?

• Razones por las que no cambiar
• ¿Para qué sirve en realidad?
• No sé si esto va a funcionar
• ¿Qué conseguiré ganar con ello?
• La gente necesitará guía, yo habré de decirles en qué consiste

¿Qué escucha (hear)?

• El mundo está cambiando
• Hay que hacerlo
• La Agilidad ayudará a nuestra compañía a crecer
• A los empleados les encanta
• Reducirá el time-to-market

¿Qué dice (say)?

• Una cosa grande para los empleados
• Buen enfoque, pero pienso que no es aplicable a mi
• Necesito más información

¿Qué siente (feel)?

• Miedo
• Inseguridad
• Incertidumbre
• Reluctancia

¿Cuál podría ser la mascota de Scrum?

La tortuga, una opción como mascota de Scrum
cortesía de Pixabay

Uno de los malentendidos más comunes sobre la Agilidad es cuando se confunde Agilidad con velocidad. Como coach ágil suelo encontrarme frecuentemente con directivos que así lo creen. Mike Beedle, uno de los firmantes del Manifiesto Ágil que propuso el nombre de Agilidad, me confesó que hubiera sido mejor utilizar el término flexibilidad.

Manoel Pimentel menciona que la mascota para Scrum podría ser una tortuga, y lo hace pensando en la fábula de la tortuga y la liebre. Me gustó mucho la idea y quiero compartir los paralelismos que hacen que la tortuga sea una buena candidata a mascota de Scrum. Recordemos la fábula:

"Una liebre y una tortuga se retan a una carrera para ver quién de las dos es más rápida. La liebre parte en cabeza y en poco tiempo coge una gran ventaja sobre la lenta tortuga. Al verse con la victoria en el bolsillo la liebre se entretiene aquí y allá, hasta permite sentarse a descansar a la sombra de un árbol y cae dormida. Cuando despierta la tortuga está a punto de cruzar la meta y pese al esfuerzo de la liebre que trata en vano de retomar la cabeza, la tortuga acaba ganando la carrera".

La moraleja de la historia es que despacio se llega lejos, y aquí está en el origen de refranes presentes en casi todos los idiomas:

• Anda despacio si quieres llegar lejos
• No temas ir despacio, solo teme no avanzar

Con Scrum los proyectos no se ejecutan mas rápido, lo que ocurre es que ponemos el foco en lo que importa, en lo que da valor de negocio, y para construir imprime un ritmo sostenido que optimiza el flujo de entrega de historias de usuario, todas ellas construidas con calidad siguiendo la definición de hecho (DoD). Si pensamos en la tortuga de la fábula vemos claros paralelismos, tiene el foco puesto en llegar a la meta y un ritmo constante que le permite llegar la primera.

Pensemos en la liebre, ¿no podríamos hacer un paralelismo con la contratación de proyectos tradicional, en los que al igual que la liebre que solo avanza entre sus paradas, los avances se producen irregularmente entre los momentos en los que los equipos ya están rodados y el fin de los proyectos donde se desmonta todo? Quizá, pero la liebre no sería una buena mascota para la gestión predictiva, pero la tortuga si lo es para la gestión ágil. ;-)

---

¿En qué situaciones es aplicable un Propietario del Producto proxy?

Propieario del Producto proxy trabajando con el equipo de negocio

En el curso troncal reciente de Scrum Manger uno de los asistentes escribió al hilo del cuarto principio del Manifiesto Ágil que establece que:

Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto

y relacionado con el rol de Propietario del Producto, le parecía interesante incidir en la naturaleza del mismo en los casos en que hablamos con un cliente que no ha interiorizado los valores del Manifiesto Ágil. Es decir le interesaba la naturaleza (o cuál debe ser) del rol de Propietario del Producto como interfaz entre un equipo de desarrollo ágil que trabaja para entregar incrementos de un producto a una organización que sigue anclada a un enfoque tradicional para la gestión de requisitos y seguimiento del proyecto.

El éxito de un proyecto depende en gran medida del desempeño correcto del rol de Propietario del Producto, ya que solo él, como responsable del producto, tiene conocimiento para tomar las decisiones correctas sobre el producto y guiar al equipo de desarrollo a través de una prioridad alineada con el valor de negocio.

El Propietario del Producto más eficiente es aquel que asuma el rol desde el equipo de negocio, desde el cliente mismo. Un proyecto no es un proyecto del equipo de informática o del proveedor, un proyecto es la construcción de algo nuevo o algo que hará mejorar o evolucionar el software que gestiona el corebusiness del cliente, por tanto un proyecto tiene una repercusión directa en la competitividad del cliente y bien liderado hará de que este venda más o se sitúe con ventaja en el mercado. La combinación que resulta en el mejor producto posible es aquel que el proyecto es liderado por el cliente y construido por un equipo de especialistas técnicos.

Hasta aquí el escenario ideal, hay otros escenarios en los que no hay posibilidad de un Propietario del Producto proveniente del cliente. Por ejemplo si no hubiera nadie del equipo de negocio del cliente formado o dispuesto a asumir ese rol, o en el caso de equipos deslocalizados en los que el Propietario del Producto colocalizado con el equipo de desarrollo no es del cliente.

En estos casos el rol de Propietario del Producto que guía al equipo de desarrollo a través del valor de negocio ha de ser alguien proveniente de TI y que desempeñe un rol de proxy entre el equipo de negocio y el equipo de desarrollo. En este caso el rol lo pueden desempeñar todo tipo de expertos como:

• Analistas de negocio - Business Analysts (BAs)
• Expertos en la materia - Subject Matter Experts (SMEs)
• Gestores y jefes de proyecto - Project Managers
• Expertos en el dominio - Domain Experts
• ...

Mi consejo es que el proxy participe en todo lo posible de las actividades del equipo de negocio, incluso que desempeñe temporalmente sus tareas para comprender con profundidad las necesidades y prioridades de negocio.

Lo que merma el desempeño del Propietario del Producto proxy es el hecho de que el poder de decisión y el compromiso no se pueden delegar, con lo que en el peor de los casos el proxy puede verse reducido a un corre-ve-y-dile entre equipo y negocio.

¿Qué es y cómo funciona el control sutil?

Para el inexperto el término control sutil podría significar un control imperceptible a la vista y con connotaciones de manipulación. Nada más lejos de la realidad en el contexto de la Agilidad. En este contexto gerencia evita el tipo de control rígido que impide la creatividad y la espontaneidad y pone el énfasis en el "autocontrol", en el "el control por peer pressure" y en el "control por amor", lo que de forma colectiva se conoce como control sutil.

Para explicar como funciona el control sutil voy a empezar con una pregunta ¿Alguna vez te has sentido absolutamente comprometido con algo que has decido hacer? Puede ser un hobby, una actividad profesional, es algo que te ha hecho entrar en flujo, una cosa con la que has disfrutado y con la que casi no podías parar hasta acabar.

Cuando nos comprometemos de forma verdadera y auténtica hacemos todo lo que esté en nuestras manos para un resultado excelente, si las cosas se tuercen duele dentro de nosotros, y entonces somos nosotros mismos los que tomamos decisiones y buscamos soluciones. Eso es control sutil, el que viene desde dentro de nosotros, desde dentro de las personas y de los equipos. Parte de ello es el control por amor en el que hacemos las cosas por amor a nosotros mismos, dejando atrás todo aquello que nos hace infeliz y focalizandonos en poner la energía en lo que nos hace feliz.

Los equipos autoorganizados no están libres del control de la gerencia ni tampoco de la influencia del sistema. Las primeras referencias a Scrum fueron claras acerca de ello en "The New The New New Product Development Game" de 1986 donde Takeuchi y Nonaka escriben que el control sutil es coherente con el carácter de autoorganización de los equipos de desarrollo. La responsabilidad de un equipo ágil trata de autoorganizarse en torno a los retos y dentro de los límites y limitaciones impuestos por gerencia. La responsabilidad de gerencia es poner los retos apropiados y eliminar los obstáculos a la autoorganización de los equipos ágiles.

Scrum implica responsabilidad y compromiso, y eso se consigue en los equipos ágiles, los que construyen y están en las trincheras, cuando se les da la responsabilidad de determinar las historias de usuario que entran en la pila de sprint.

Si por ejemplo hay 10 historias de usuario por construir, se le dice al equipo que elija las que honestamente cree que puede construir en un entorno correcto en las próximas dos semanas, y elijen 5 por ejemplo ¿no darán todo por hacerlo bien? Cuando somos nosotros mismos quienes decidimos cuanto y como vamos construir nos duele mucho cuando las cosas se tuercen, y trataremos de hacer todo lo posible por cumplir con nosotros mismos: eso es fruto del control sutil.

En los equipos ágiles, en los que el objetivo es común y los fracasos y éxitos son compartidos, se suma la peer pressure, la presión que sentimos cuando uno de los miembros no se siente a la altura del equipo, del que siente que forma parte y que son sus compañeros de viaje a muerte.

Equipo: uno para todos, todos para uno - cortesía de Pixabay

Uno de los problemas que tenemos en nuestra cultura empresarial, en la que gestionamos proyectos en que creamos equipos para cada proyecto, es que al inicio realmente no tenemos un equipo, tenemos un grupo de personas susceptibles de ser equipo. Con el entorno y acompañamiento correctos la naturaleza humana llevará a formar equipo, las personas nos gusta, hasta diría que necesitamos, formar equipo.

En un equipo ágil de verdad cada miembro se siente acompañado, siente que aporta, tiene absoluta confianza en los demás, siente que va en el mismo barco que los demás, sabe que le apoyaran en sus equivocaciones, igual que él apoyará a los de los demás... es lo que también se llaman equipos de excelencia o tiger teams... y el control que les aplica es el control sutil.