El Acta de constitución del equipo Ágil se centra en la visión (el "por qué") y la forma de trabajo en equipo. El SPI y el CPI son métricas de gestión del valor ganado de una metodología predictiva del proyecto, y no forman parte de una Acta de Constitución del Equipo Ágil.

Las revisiones de iteración (sprint) son para las demostraciones de productos. Las retrospectivas de iteración (sprint) son realizadas para obtener lecciones aprendidas (de ese periodo) y en ellas nos preguntamos "Qué salió bien, qué no salió bien y qué podríamos mejorar".

Los Proyectos Ágiles se centran en ofrecer valor empresarial y en trabajar atentamente con los clientes y los representantes empresariales para asegurar de que el valor sea siempre el correcto. Los riesgos comerciales y el impacto de no emprender el proyecto debe ser también considerado.

El enfoque ágil es una combinación de entrega incremental y desarrollo iterativo. Esto significa que el valor comercial se mejora y prioriza de manera continua e iterativa, mientras que tambien es entregada en incrementos que los clientes pueden ver, sentir y tocar. Las funciones deben estar completas, probadas y la calidad es responsabilidad de todos.

El dueño del producto representa al cliente al que le está entregando valor comercial. El equipo trabaja de acuerdo a la lista priorizada de trabajo pendiente (lista de ítems del backlog) que tienen valor indentificable y han sido priorizados por el cliente.

Un proyecto ágil puede aceptar cambios incluso en una fase avanzada del desarrollo. Pero mientras las restricciones competitivas de costo, calidad y cronograma son a menudo fijados, en ágil el alcance puede variar. Esto significa que es posible que algunas funciones deban retirarse y otras sean re-priorizadas. También se requiere un trabajo sostenible (El gerente del proyecto no debe pretender que el equipo se sobreesfuerce, aduciendo la "necesidad" de incrementar el ritmo del trabajo del proyecto).

El estilo preferido de liderazgo en un equipo Ágil es Liderazgo de Servicio, el Liderazgo Autocráctico suele ser asunto de una sola persona, mientras que el liderazgo de servicio crea seguridad psicológica para que todo el equipo participe y contribuya. Todos los demás elementos enumerados son prácticas Ágiles básicas.

Si bien informar a los ejecutivos tiene su lugar cuando ejecutan un proyecto, en el enfoque ágil se prefiere hacerlo incluyéndolos en otras prácticas básicas ágiles, tales como las demostraciones o revisiones del producto, mostrando gráficos de burndown y la acumulación de trabajo completado, por ejemplo. Los demás elementos son prácticas básicas ágiles.

El trabajo en pares, swarming y mobbing son técnicas válidas de gestión y colaboración del trabajo en progreso (WIP). La multitarea se considera un factor que afecta el desempeño de los equipos en los entornos ágiles.

Si la organización se descompone en silos departamentales, eso impide la entrega acelerada y no fomenta la formación de equipos multifuncionales. El resto de las opciones son atributos deseables.

Una manera adecuada de estimar un proyecto ágil es mediante una medición abstracta que se base en un elemento del Backlog que conocemos su dificultad y le damos un valor y en función de esta historia damos un valor de dificultad a cada historia restante. Se suele usar la serie de Fibonacci para esta estimación.

La ley de rendimientos decrecientes dice que a partir de cierto punto, al incrementar los recursos, la producción aumenta a tasa decreciente.
La Procrastinación, Ley de Parkinson y el Síndrome del estudiante suelen agregar riesgos de retraso en la duración de actividades.
Procrastinación: No realizar las actividades por estar distraído en cosas cotidianas (Internet, celular, etc.).
Ley de Parkinson: Las actividades se extienden el tiempo disponible.
Síndrome del estudiante: Dejar las actividades hasta el último minuto.

Los equipos ágiles utilizan prototipos, demostraciones y revisiones para comprender y perfeccionar el alcance del proyecto, lo que permite una rápida entrega de un producto funcional.

El método de priorización MosCow etiqueta las tareas como debe tener, debería tener, puede tener y no tendrá (o le gustaría tener). Otras técnicas de priorización son los votos múltiples con puntos, dinero monopólico, análisis Kano y el puño de cinco.

Las "revisiones de iteración (sprint)" Ágiles, o las demostraciones de funciones, ocurren en el final de una iteración (sprint)o cuando se han completado suficiente tarjetas o funciones en un conjunto que puede ser exhibida.

Ágil se desarrolla y se entrega en funciones o incrementos. Esto significa priorizar, desarrollar y probar para cada incremento. Aunque queremos entregar rápidamente, las pruebas de calidad siguen siendo importante y la calidad es responsabilidad de todos.

La integración continua combina el código en un entorno de prueba mediante un proceso automatizado, incluyendo pruebas de regresión automatizadas para asegurar que nada esté roto. Esto permite al equipo encontrar y corregir defectos en el código con mayor rapidez. El Desarrollo Basado en Pruebas escribe una prueba (el cual falla al principio) en el código para asegurar que la prueba pasa.

La integración continua está diseñada para unir todos los cambios realizados en el software y probarlos automáticamente, descubriendo cualquier defecto o problema a diario.

Los indicadores clave de rendimento de en un proyecto ágil incluyen la velocidad del equipo (tasa de progreso) y el trabajo restante. Esto puede ser mostrado visualmente tan bien como en una gráfica de trabajo pendiente frente al tiempo restante (burndown chart). Revisando estos KPIs podrás dar una respuesta más fiable.

En Ágil, el trabajo se asume en base a las velocidad del grupo o la taza de trabajo. La pizarra Kanban muestra el WIP y quien está trabajando en qué. Conocer la velocidad le permite realizar suficiente trabajo, pero no demasiado. La investigación ha demostrado que las tareas de conmutación multitarea en realidad reducen la efectividad a medida de que el equipo se pone al día.

Un líder de servicio incluye al grupo en decisiones y lo hace crecer a través de la educación y el compromiso.

El contacto frecuente en los proyectos de enfoque ágil está ahí para asegurar que las funcionalidades sean revisadas y cumplan con las expectativas de los interesados y que los riesgos sean abordados. Esto permite plantear cambios de forma anticipada. Asimismo, esto enfatiza que la calidad es responsabilidad de todos en un equipo ágil.

Cuanto más se demore en entregar una funcionalidad, mayor es el riesgo que la funcionalidad no proporcione el valor que se pretendía proporcionar. La entrega impulsada por el valor prioriza las funcionalidades por el valor más alto y busca entregarlos rápidamente para obtener el máximo beneficio para el cliente.

Un equipo ágil entrega en incrementos e itera las mejoras. Al priorizar primero las funcionalidades de alto riesgo, aplicando el principio de "equivocarse rápido, aprender rápido y corregir rápido", se reducen los riesgos futuros para lo que viene en el proyecto.

El Líder de servicio enfoca el trabajo empezando con el propósito o el "por qué" detrás del trabajo, luego trabaja con personas en crecimiento y desarrollo y finalmente asegura un proceso sólido para hacer que el trabajo suceda.

El líder de servicio en Ágil entrena al equipo, fomentando la seguridad psicológica y la confianza, y promueve la energía y la inteligencia de los demás. El enfoque no incluye el liderazgo directivo u obliga a otros de hacer lo que tú dices.

El rol de dueño del producto representa al cliente o el área que obtiene el beneficio de valor entregado por el equipo Ágil. Debido a esto, ellos a menudo tienen conocimiento profundo que esa área, saben qué aportará más valor y pueden priorizar los elementos de trabajo eficientemente.

Ágil trabaja en una entrega continua y sostenible. Presionar al equipo más allá del los limites de conocimiento no es una parte de la práctica Ágil. Una vez la Velocidad del equipo es conocido, es una buena práctica establecer un límite WIP para iteraciones futuras para no sobrecargar al equipo. Los miembros del equipo aun pueden obtener nuevas tarjetas para trabajar si ellos terminan el trabajo existente y en ese momento puede revisar la velocidad del equipo.

La lista de trabajo pendiente (backlog) ajustada al riesgo es una acumulación de sprint o lanzamiento que contiene tareas de respuesta al riesgo para riesgos accionables. Esto será priorizado contra las funciones normales, también en la lista de trabajo pendiente (backlog), para ajustarlo para el riesgo.

El riesgo es mayor al principio del proyecto antes de que se hayan completado los elementos. Al completar primero los elementos de alto riesgo, estás reduciendo significativamente esos riesgos y la amenaza de lo desconocido más adelante del proyecto.

Un equipo Ágil está compuesto de especialistas "generalistas" o personas con "habilidades en forma de T" con un profundo conocimiento en un area, y una amplia gama o experiencia en otras áreas. Todo el equipo es responsable de los riesgos en un equipo ágil. Reducir equipos es solo aplicable para equipos maduros que se están desempeñando bien y pueden reducir el tiempo y esfuerzo.

La resolución de problemas se realiza con el equipo Ágil. Los impedimentos se plantean lo más pronto posible - al menos durante una reunión diara, para que el equipo pueda abordar el problema, aplicando el enjambre entre otras técnicas, tener la ayuda de los expertos necesarios y seguir adelante.

La seguridad psicológica es una de las partes más importantes de un equipo altamente funcional, que significa tener la seguridad de ser vulnerable, admitir problemas, pedir ayuda y mejorar. Esto empieza con el líder y el liderazgo de servicio contribuye en esto.

Demostrar el incremento utilizable desarrollado durante una iteración (sprint)al cliente o dueño del producto, garantiza que la retroalimentación se recopile más rápidamente que solo al final de un proyecto. Las retrospectivas es otro método de retroalimentación sobre el proceso del equipo.

Un equipo Ágil últimamente sirve a los clientes y en muchos casos el cliente es el dueño comercial o representante. Si ellos no son también dueños del producto (o familiarizado con esa forma de trabajar) debes mostrales la velocidad del equipo en comparación a la cantidad de puntos asignados actualmente, si deben priorizar las funciones que desean a continuación. Esto les da control sobre la entrega de valor mientras no sobrecarga al equipo.

Ágil usa retrospectivas al final de cada iteración (sprint) con el equipo completo, para preguntar "¿Qué fue bien?", ¿"Qué no fue bien"?, "¿Qué pude aprender?" y "¿Qué sigue desconcertándome?" Las lecciones de esta sesión se tratan de poner en en práctica y se incorporan de nuevo en iteraciones futuras para mejorar rápidamente.

Ágil usa bosquejos (mock-ups) fáciles de ver o prototipos como los guiones gráficos (storyboards), esquemas de páginas o modelos para tener un rápido entendimiento del requisito y consenso de todas los públicos de interés.

Los prototipos, esquemas de página y guiones gráficos son maneras importantes de reunir retroalimentación y que esta permita al público de interés (stakeholder) discutir y acordar los requisitos y funciones del producto antes de que se gaste el dinero en desarrollos actuales.

Las retrospectivas son reuniones establecidas al final de cada iteración (sprint)que pide activamente retroalimentación con ciertas preguntas: ¿Qué salió bien? ¿Qué no fue bien?, ¿Qué me sigue desconcertando? Las acciones de estas preguntas se incorporan de nuevo en el equipo en futuras iteraciones.

Los Cinco Por qué's es una técnica de resolución de problemas proveniente de Lean que pregunta el "por qué" de un problema ocurrido. Para cada respuesta, el equipo pregunta "por qué" de nuevo, hasta tener la causa real del problema.

La autoevaluación del equipo es usado para medir el desempeño de los miembros del equipo en conjunto, con los resultados ayudar a identificar qué está trabajando bien y dónde las mejoras pueden realizarse. El equipo luego se reúne para resolver problemas de mejoras y celebrar lo que está funcionando bien.

El Scrum of Scrums permite a ambos equipos tener sus propias reuniones diarias mientras agregan una reunión más específica entre ellos a un ritmo menos frecuente.

El mejor enfoque es invitar a las partes interesadas a participar en la revisión, ya que la iteración está casi completa. Esta es la opción más directa y adecuada para involucrar a las partes interesadas.

Los requisitos y comentarios de los usuarios finales reales NO PUEDEN ser reemplazados por estructuras organizativas, simulaciones o conjuntos de características generalizadas (accesibilidad). La contratación con el departamento de usuarios finales tampoco sería apropiada, ya que NO tendrían experiencia, normas y activos relacionados con la forma en que el software se integra en el entorno de TI más grande.

También conocido como daily scrum, la reunión diaria de a pie (daily Standup) es una reunión breve de 15 minutos en la que todo el equipo se reúne para una actualización rápida del estado mientras está de pie en círculo. Idealmente, las reuniones stand-up deben llevarse a cabo al inicio del horario laboral y la presencia de todos los miembros del equipo involucrados en el Sprint es obligatoria.

El liderazgo considerará las particularidades del equipo y la situación del proyecto.