La introducción definitiva a la gestión ágil de proyectos

La breve

Usted está a cargo de entregar la última y mejor iniciativa de su empresa que cambiará la cara de "Widgets International" para siempre. Es un proyecto de software que atraerá y cautivará a sus clientes, facilitará la vida de sus colegas y generará ingresos millonarios para la empresa. Hay una gran cantidad de anticipación, fervor, entusiasmo y expectativa. Debe hacerlo lo más rápido posible para que su negocio pueda comenzar a cosechar los beneficios. El éxito futuro de la empresa depende de usted. Todos los ojos están puestos en ti. No puedes fallar.

Al principio, estás pensando para ti mismo: “Impresionante, estoy listo para el desafío. ¡Terminemos con esto!” Hace una pausa por un momento, da un paso atrás y piensa para sí mismo: "Está bien, entonces, ¿cómo hacemos esto?" Empiezas a hablar con tus colegas y compañeros. Pasa tiempo buscando las mejores prácticas de desarrollo de software y técnicas de gestión de proyectos, pero las opciones y los enfoques son innumerables. Hay acrónimos y metodologías en abundancia. Los notables suben a la cima. La duda se cuela. ¿Cuál deberíamos usar? ¿Cómo puedo garantizar el éxito? ¿Qué pasa si tomo las decisiones equivocadas?

Cuando se trata de administrar proyectos de software, existe una combinación embriagadora de opciones respaldadas por innumerables opiniones. Voces desde los rincones de la habitación susurran: “Intenta hacerlo de esta manera”; otros gritan: “Esta es la única manera de hacerlo”; y el resto simplemente gimotea: "No lo manejes en absoluto, solo sigue adelante". En realidad, todas esas voces dicen algo de verdad. Pero lo importante es determinar qué es lo correcto para sus necesidades, su equipo, su empresa y sus clientes.

Preparando la escena

Hubo un tiempo en que la gestión de proyectos de software se sentaba directamente en uno de los tres campos. Estaban los marcos pesados ​​que le permitían tomar decisiones sobre cómo ejecutar y entregar mientras ofrecía una estructura para mantener el control y la gobernanza. Había metodologías secuenciales prescriptivas como la cascada que lo obligaban a planificar proyectos extensos, comprender y comprometerse con todos sus requisitos, diseñar y aprobar sistemas complejos, escribir mucho código y luego probar (todo antes de que su cliente lo vea por primera vez). hora). Y, por último, los ciclos de vida de desarrollo de software (SDLC) menos prescriptivos pero iterativos que fomentan la creación rápida de prototipos o el diseño, la construcción y la entrega de sistemas más grandes en pasos incrementales, cada uno construyendo sobre el otro.

El desarrollo de software ágil y la gestión de proyectos ágiles nacieron de las deficiencias de la cascada y los beneficios de los enfoques iterativos para la entrega de software. Pueden rastrear sus raíces hasta la década de 1950, el liderazgo intelectual en la década de 1970, la madurez en la década de 1990 y la adopción hasta la década de 2000. En 2001, un grupo de profesionales y expertos crearon el Manifiesto Ágil, con el objetivo de definir 4 valores y 12 principios rectores que buscan encarnar el espíritu del desarrollo de software Ágil y fomentar su evolución. Y definitivamente ha evolucionado.

Ahora, simplemente llamar a algo Agile no es particularmente útil. La palabra, incluso en un contexto de software, significa diferentes cosas para diferentes personas u organizaciones. Hay muchas facetas, definiciones, implementaciones e interpretaciones. Cada organismo que adopta Agile tiende a intentar darle su propia definición.

Baste decir que el desarrollo de software ágil y la gestión de proyectos son un grupo de comportamientos, marcos, técnicas y conceptos relacionados que favorecen fundamentalmente la entrega del software de trabajo adecuado tan pronto como sea posible y con la mayor frecuencia posible.

Mencioné anteriormente que Agile, tal como se aplica al desarrollo de software o la gestión de proyectos, puede ser cosas diferentes. En pocas palabras, el desarrollo de software Agile se encarga de desarrollar un gran software en un contexto de proyecto o business as usual (BAU). La gestión ágil de proyectos, por otro lado, se ocupa de la gobernanza y el control necesarios para entregar proyectos complejos que incluyen, entre otros, software.

Hay muchos métodos ágiles de desarrollo de software disponibles, como Scrum, Kanban, XP y Lean Software Development. Pero así como el juego de rugby es más que el scrum, Agile también lo es. De forma aislada, estos paradigmas ágiles no abordan el ciclo de vida completo de la gestión de proyectos que se requiere en proyectos complejos como la gobernanza, los recursos, las finanzas, la gestión de riesgos explícitos y muchos otros conceptos importantes de gestión de proyectos. Para estos, es posible que desee considerar PMI Agile o PRINCE2 Agile; piense en ello como "Agilidad gobernada".

¿Por qué necesitamos ser ágiles?

Hace mucho tiempo, vagamos por la tierra para recolectar comida y refugio para sobrevivir. Eran necesidades simples, pero bastante ágiles. Algún tiempo después, los países y las economías crecieron y prosperaron gracias a la Revolución Industrial. Este fue el nacimiento de la gestión y el control y la pérdida de agilidad. Ahora estamos en la Era de la Información o Revolución, donde las empresas emplean trabajadores del conocimiento. Los trabajadores del conocimiento son usted, sus socios y sus colegas y compañeros, que se esfuerzan por crear grandes soluciones para los problemas de los clientes, comerciales, sociales, económicos y mundiales. Los trabajadores del conocimiento aplican el análisis, el conocimiento, el razonamiento, la comprensión, la experiencia y las habilidades a necesidades cambiantes y a menudo vagamente definidas. Estas empresas y trabajadores necesitan métodos y técnicas que no pueden cumplir los procesos y procedimientos de la antigua Era Industrial. Agile admite interacciones.

Prácticamente ningún proyecto de software puede comenzar con confianza desde el principio y saber todo lo que necesita para entregar un valioso software que funcione sin cambios. El cambio presenta tanto oportunidades como riesgos para el éxito de un proyecto. Las oportunidades no gestionadas pueden significar la diferencia entre una gran empresa y una empresa increíble. El riesgo no gestionado significa desastre y ruina. Agile gestiona el cambio.

La adopción de Agile le permite ser receptivo a los requisitos cambiantes o nuevos. Capacita a los equipos de desarrollo para que sean expertos y tomen decisiones con el apoyo de una empresa comprometida, confiable e informada. Le permite ofrecer a los clientes lo que realmente quieren. En última instancia, le da a usted y a su organización el control de la entrega de software valioso y de alta calidad que cumple con las necesidades y expectativas del cliente al tiempo que obtiene un retorno de su inversión lo antes posible. Ágil crea valor.

La adopción de Agile tiene un costo. No viene gratis. La transformación a un enfoque Agile para la entrega de software puede ser un camino difícil de seguir. Sin embargo, si interioriza la filosofía Agile, avanza con cuidado, involucra al equipo correcto con la actitud correcta, desglosa las cosas, hace que sea alcanzable y realista, y responde a los comentarios, obtendrá recompensas. Agile enfatiza la colaboración.

A continuación se enumeran algunos beneficios que puede esperar:

• Velocidad de comercialización
• Generación de ingresos más temprana
• Entrega regular de valor real
• Protección para su inversión
• Datos, datos, datos
• Mejor calidad del producto
• Expectativas manejables
• Mayor satisfacción del cliente
• Equipos de mayor rendimiento
• Visibilidad mejorada del progreso
• Previsibilidad, transparencia y confianza
• Riesgo manejable

El éxito no es definitivo, el fracaso no es fatal: lo que cuenta es el coraje de continuar.

Es posible que Winston Churchill nunca haya dicho esto, pero creo que es un resumen bastante bueno de Agile. Sabemos que Agile es el mejor paso adelante para la mayoría de los proyectos. Lo alienta a luchar por el éxito, pero siempre iteramos y seguimos construyendo sobre eso. Agile lo alentará a fallar, pero falle temprano y siga adelante. Tener el coraje de continuar y construir la solución correcta basada en el conocimiento informado por su cliente es lo que trae la recompensa.

Lo que debe tener en cuenta es que puede adaptar Agile a sus necesidades. Utilice el método y la gobernanza adecuados para su empresa. Dondequiera que comience, sea fiel al contenido, el contexto y el espíritu del método que utiliza, manténgalo simple. Si estás empezando, infórmate . Si lo has estado haciendo por un tiempo, entiéndelo . Si te estás volviendo increíble, aplica . Finalmente, si su negocio y sus proyectos son complejos e interdependientes, gobierne . Con el tiempo, usted y sus equipos descubrirán qué funciona mejor para su negocio.

Factibilidad

Así que ahora estás pensando, “Está bien, lo entiendo. ¿Como empiezo? ¿Dónde empiezo?" Bueno, con todo lo bueno, empecemos por el principio. Y con Agile, es preguntándose "¿Qué valor comercial quiero ofrecer?" Al fin y al cabo, para eso emprendemos proyectos, para generar valor empresarial. Para establecer si vale la pena emprender el proyecto para obtener el valor comercial, debe comprender si es factible.

Visión

¿Está proyectado que su proyecto aumente los ingresos, ingrese a un nuevo mercado, adquiera más clientes, mejore la percepción del cliente o haga la vida más fácil para un problema determinado que ha identificado? Con esto en mente, puede declarar su “visión”.

• Su visión puede provenir de diferentes fuentes: su propia puesta en marcha audaz para solucionar un problema común, la estrategia de gestión empresarial, el proyecto favorito de su director ejecutivo, un equipo de producto específico o incluso las necesidades de su cliente.
• Trate de dar un paso atrás de sus propios zapatos y "ver" cómo se ve el futuro con su nuevo producto o servicio en manos de sus clientes.
• Involucre a sus partes interesadas: el director ejecutivo, el encargado del producto y los clientes. Taller, no intente esto de forma aislada. Desafíe las suposiciones y valide los argumentos.
• Escríbalo, sea breve. Centrarse en el valor del negocio.
• Refínelo hasta que todos estén de acuerdo en que la visión resuena con todos y se encuentra con una interpretación común que establece hacia dónde se dirige.
• Su visión, si es válida, rara vez cambia. La forma en que llegue allí seguramente lo hará.

La gente no compra lo que haces, o cómo lo haces. Compran el "por qué" lo haces. Esto es lo que crea la conexión emocional entre su negocio y sus clientes. La visión ayudará a ilustrar esto.

¿Es factible?

La viabilidad viene en al menos un par de tonos. Por lo general, querrá comprender si su visión de un futuro mejor para su empresa y sus clientes es técnicamente factible y si es factible que su empresa lo haga realidad.

• Si su visión es viajar a cualquier parte del mundo en menos de una hora, es posible que tenga un problema con la viabilidad técnica. Dado que la ciencia, la física y la tecnología aún no han alcanzado ese sueño, es posible que su solución técnica no sea viable en otra cosa que no sea la teoría. Además, si su solución fuera nueva, iría mucho más allá de la idea de un producto mínimo viable (MVP).

• Para probar la viabilidad técnica de su producto, considere explorarlo más a fondo en un proyecto de prototipo Discovery o ejecutar un pico en las primeras etapas del proyecto. Sabrá qué método usar pensando en la escala o complejidad de la solución que tiene en mente.

  “Algunos de los mejores conocimientos que han adquirido mis equipos en la comprensión de la viabilidad técnica provienen de realizar un remate. ¡Y a menudo, es la solución más simple la que gana!”

• El segundo tono de factibilidad a considerar es si usted, su equipo o su negocio tienen las habilidades y la motivación para hacerlo funcionar. Usando un ejemplo, si eres bueno horneando pasteles en casa para el cumpleaños de tus hijos, eso es genial. Pero si desea convertir esto en un negocio que venda los pasteles más finos del mundo, debe comprender si puede escalar, manejar el negocio y la producción, administrar la distribución y el cumplimiento, y cuidar el servicio al cliente.
• Este tipo de visión podría lograrse a largo plazo. Pero por ahora, posiblemente no. Así que redúzcalo, piense en pequeño, tome una pequeña parte que parezca realista y concéntrese en ofrecer la mejor aspiración más pequeña que pueda. Si eso logra atraer y deleitar a sus clientes, haga que regresen por más y se lo cuenten a sus amigos, luego amplíe desde allí utilizando los comentarios de sus clientes como guía y brújula.
• Además, necesita saber si su proyecto es factible en términos de presupuesto y plazo. ¿Puede su empresa permitirse entregar este proyecto? ¿Es alcanzable el plazo? El tiempo y el dinero son dos de las tres limitaciones en un proyecto Agile que son fijas. Nuestro objetivo es entregar dentro de un tiempo fijo determinado y dentro de un presupuesto fijo determinado.
• La calidad de un producto se refiere al producto final que usan sus clientes y las prácticas de ingeniería que usa su equipo para entregar un software excelente, sólido y confiable. La calidad también es algo que no defraudamos. Los criterios de calidad, por otro lado, pueden cambiar. Si no se propone construir un Ferrari, es posible que el producto no tenga una percepción de alta calidad. Si no está construyendo cohetes espaciales, entonces las tolerancias alcanzadas en términos de producción pueden ser mucho más altas. Establezca el tono y la expectativa apropiados desde el principio.

Entonces, ahora que ha confirmado que su sueño es más que una fantasía de chocolate, comience a probar sus suposiciones y demuestre a las personas que vale la pena invertir en este esfuerzo.

Justificación

Ahora, dependiendo de tus circunstancias, la justificación vendrá en diferentes formas. Pero esencialmente, desea demostrar que este proyecto satisfará los criterios de éxito del cliente, tiene posibilidades de éxito, generará valor y será asequible.

• Indique sus suposiciones en función de las necesidades de su cliente y luego valídelas. Lean Startup brinda una excelente guía para identificar y demostrar que sus clientes necesitan su producto y que creará valor.

• Escriba, pruebe y valide su plan de negocios. Ahora bien, esto no se parece en nada a los que su banco o su especialidad en negocios y finanzas le dijeron que produjera. No los use, estarán desactualizados antes de que la tinta se seque. En su lugar, consulte el Business Model Canvas. Este es esencialmente un plan de negocios breve que mantiene su enfoque en su propuesta de valor, sus clientes, ingresos y costos. Úselo para validar si tiene un negocio que funcionará.

  “Ignoré este consejo una vez y pasé mucho tiempo escribiendo un largo plan de negocios tradicional de 50 páginas. No me llevó a ninguna parte. Todas las suposiciones que había hecho eran infundadas y todas las proyecciones que hice no pudieron ser validadas. Fue una experiencia dolorosa y costosa que me enseñó a nunca volver a hacerlo”.

• Si está en un negocio maduro con carteras de proyectos que se entregan en un entorno complejo, entonces puede ser necesario el modelado financiero. Si es necesario, hazlo solo después de haber probado lo anterior.
• Una vez que haya construido su MVP, puede haber un caso para crear un plan de negocios más tradicional, por ejemplo, si tiene que buscar financiación o selección dentro de la cartera de proyectos y recursos competitivos de su empresa. Pero este será un plan de negocios basado e informado por las herramientas utilizadas anteriormente. Será más ligero también.
• En cualquier caso, utilice estas herramientas como artefactos vivos que respiran. Úsalos como tu guía y referente. Nunca son estáticos. Consúltelos y revíselos a medida que su proyecto o negocio evolucione.

Una vez que tenga su justificación y todas las partes interesadas estén a bordo, estará en llamas.

La fase de factibilidad generalmente se realiza una vez en la vida de su proyecto. Es posible que vuelva a revisar la visión y la viabilidad del proyecto, especialmente si sus datos, clientes, mercado o negocio así lo indican. Como mínimo, serán sus luces de guía en todo momento.

Iniciación

Increíble. La decisión está tomada, el proyecto tiene luz verde y estás listo para construir. Bueno, casi. Sé que estás pensando, “Vamos ya, ¿en serio? Si no hacemos esto ahora, nunca lo haremos. ¡Pongamos este espectáculo en marcha!”. Pero considere esto: Agile no es más que entregar valor temprano y con frecuencia mientras deleita a sus clientes en el camino. Tomarse un tiempo para descubrir la mejor manera de entregar su proyecto es la mejor base para el éxito.

El equipo

En los deportes, al pensar en su juego de equipo favorito, podrá reconocer los roles clave que permiten que el equipo se desempeñe como lo hace. Tradicionalmente, encontrarás un entrenador, un capitán y el resto del equipo. Aparte de eso, encontrará entrenadores, fisioterapeutas, nutricionistas y una variedad de personal de apoyo. Pero si miramos el juego de rugby, hay un equipo dentro de un equipo: los jugadores que forman el scrum. Este grupo está formado por jugadores designados cuyo trabajo es recuperar el balón y continuar el juego. Cuando un scrum está en juego, los jugadores de cada lado trabajan, sin líder, como una sola unidad de la manera más colaborativa, comunicativa y eficiente posible para recuperar la posesión del balón. Es el juego de rugby que inspiró a Jeff Sutherland a nombrar su metodología de desarrollo de software "Scrum".

• Scrum no es el único método de desarrollo de software en el libro de jugadas Agile. Pero es el que mejor describe el concepto ágil y los comportamientos de trabajar en equipo, motivar a las personas, crear relaciones de confianza, autoorganización, liderazgo de servicio, comunicación, transparencia y colaboración.
• Tu equipo estará formado en gran parte por las circunstancias en las que te encuentres. Es posible que tengas desarrolladores disponibles para ti. Algunos, ninguno o todos ellos pueden estar familiarizados con Agile en diversos grados. Es posible que desee contratar un nuevo equipo o asociarse con un tercero.
• También se requerirán otros roles, pero los discutiremos más adelante.
• Se ha dicho que si formas parte de tu equipo de desarrollo, entonces has elegido tu tecnología. Dependiendo de dónde reúna a su equipo, vendrán con conjuntos de habilidades específicas. Por lo tanto, piense detenidamente cómo formará su equipo de desarrollo y si necesita realizar una evaluación técnica antes de llegar a este punto de su viaje.
• Esto nos lleva a los equipos multifuncionales. Los equipos funcionan mejor cuando trabajan juntos, cuando las personas colaboran para hacer el trabajo independientemente de su título. Trate de construir un equipo que sea autosuficiente e individuos que asuman más de un rol.
• Cree un entorno, una cultura y un centro de relaciones, un lugar donde el equipo pueda cumplir, sin limitaciones ni restricciones. Proporcione al equipo las herramientas, las personas, los recursos y el espacio para ser eficaz y eficiente.
• Mantenga el tamaño de los equipos en no más de siete u ocho. Si necesita muchos más desarrolladores, divida el equipo en varios equipos nuevos. Cada equipo podría entonces ser responsable de un área funcional determinada. Si tiene varios equipos en varias ubicaciones, considere realizar un Scrum de Scrums. Y cuando estos sean numerosos en entornos complejos, utilice la gestión de proyectos Agile.
• Asegúrese de que el equipo, el negocio, las partes interesadas e incluso los clientes tengan acceso entre sí. Asegúrese de que se comuniquen y colaboren, y elimine todo lo que se interponga en el camino del progreso. La comunicación diaria es la mejor cura para las dolencias del proyecto. Cuando la gente habla, hace las cosas.

Hay muchas maneras en que se puede formar un equipo para entregar software.

Resumen del proyecto

En el paso de factibilidad, descubrió el "por qué" de su proyecto y construyó su confianza para seguir adelante con su puesta en marcha o obtuvo respaldo para continuar. El resumen del proyecto es el documento vivo que reúne el "por qué" con el "qué", el "cuándo" y el "quién". Es “vivir” porque, a medida que avanza, su conocimiento, comprensión y camino pueden cambiar. Dejar este documento una vez escrito y nunca volver a él simplemente consigna sus pensamientos a un punto en el tiempo. En un mundo Agile, su punto de referencia en el tiempo puede cambiar semanalmente o incluso diariamente, por lo que es importante mantener esto actualizado.

• Una gran herramienta para encapsular y mantener el resumen de su proyecto es algo que Jonathan Rasmusson llama el "mazo de inicio" en su libro The Agile Samurai . Aquí encontrará excelentes consejos para garantizar que todos los interesados, afectados o involucrados en su proyecto estén en sintonía.
• El mayor enemigo de la entrega de proyectos es tener una comprensión poco clara, inconsistente o simplemente diferente de lo que es el proyecto y qué "requisitos" deben cumplirse. Si incluso una parte interesada importante tiene una comprensión o visión diferente de lo que está haciendo, las consecuencias pueden ser sustanciales.
• Un buen resumen del proyecto comunica:
  1. Una expectativa común y acordada entre las partes interesadas y los miembros del equipo.
  2. Una comprensión del proyecto, con la misma comprensión en todas las partes.
  3. La meta, visión, objetivo, alcance y contexto del proyecto.
• Obtendrá mucha información útil para el informe recopilada a partir de la factibilidad. El resumen del proyecto lo ayudará a definir y encontrar las respuestas a las preguntas de búsqueda. Reunirá a las partes interesadas, su razón de ser , alcance de alto nivel, riesgos, solución objetivo, presupuesto, cronograma, expectativas y prioridades.

Una vez, un colega me detuvo en un pasillo y me preguntó dónde podía conseguir el resumen del proyecto. Bromeé 'No necesitamos un resumen, somos ágiles'. Parecía confundido, como si estuviera cuestionando mi cordura o autoridad. Tenía razón al hacerlo.

Antes de continuar, asegúrese de que todos estén en sintonía, practique el taller, haga las preguntas difíciles y colóquelo en algún lugar donde las personas puedan detenerse, leerlo, comentarlo y ayudar a revisarlo.

Cultura y Formas de Trabajo

Conoce la forma en que funciona su negocio y su cultura, la forma en que le gusta hacer las cosas. Agile, por su propia naturaleza, puede desafiar algunas de estas formas de trabajar que su empresa ha cultivado a lo largo de los años. No espere que se implemente Agile y que todos lo adopten con amor desde el principio. Algunas personas pueden encontrarlo confuso y verlo solo con pavor y miedo. Algunas personas pueden negarse abiertamente a participar en él. Estos son desafíos y percepciones que debes superar. Pero en sus primeros días, no ande agitando el palo Agile golpeando a cualquiera que no quiera escucharlo. Eso no generará confianza, adopción o compromiso.

Una vez fui fanático de agitar grandes palos proverbiales, y me ganó mucha prensa negativa. Le di la vuelta, no sin antes sufrir un dolor considerable.

Al emprender el camino de la adopción, camine con cuidado, respeto y empatía. Si usted está en un negocio tradicional viejo y chirriante, tal vez no sea el mejor enfoque para alinear todo el negocio. Comience poco a poco y gane gradualmente respeto y reconocimiento. Comience solo con su equipo. Una vez que comience a ofrecer software más rápido y con mejor calidad que nunca, la gente comenzará a notarlo y querrá venir a jugar su juego. Cuando lo hagan, ofrézcales la pelota, llévelos a tomar un café y llévelos a su nuevo mundo. Ayudarles a.

Con su equipo, ahora que saben de qué se trata el proyecto y sus planes para la adopción de Agile están acordados, deje que el equipo decida cómo desea comportarse y operar como equipo.

• Guíe a su equipo para identificar los conceptos, técnicas, comportamientos y marcos ágiles que considere que se ajustan a sus necesidades colectivas.
• Tome las solicitudes de los miembros de su equipo en cuanto a los requisitos que tienen para ayudarlos a desempeñarse lo mejor que puedan. Algunas de estas solicitudes, podrás resolverlas inmediatamente. Otros, es posible que necesite obtener un presupuesto o ayuda externa. Haz lo que puedas para que esto suceda.
• Estos son sus primeros pasos para convertirse en un verdadero servidor-líder.
• Considere organizar una capacitación adecuada en los conceptos y técnicas que su equipo está eligiendo adoptar. Esta es la mejor manera de asegurarse de que todos los miembros de su equipo, incluso las partes interesadas, estén en la misma página y reciban el mismo mensaje. Trabaje con una organización proveedora que pueda adaptar su oferta a sus necesidades.
• Se prudente. Nadie será un ninja ágil después de unos días en un taller aprendiendo cómo volverse ágil. Tu camino será largo. La palabra "convertirse" es bastante definitoria. Solo cuando realmente adopte Agile verá su valor. Debería emocionarte. Si te emociona, ve y emociona a los demás también.
• Ahora que su equipo acordó los conceptos y las técnicas, cumplió sus deseos y está en capacitación Agile, dirija la atención de su equipo hacia sí mismo y lo que esperan de usted, del negocio y de los demás.
• Definir algunas formas de trabajar (WoW) dentro y por parte del equipo ayuda a generar confianza, relación y expectativas. El WoW no es Guerra y Paz . Debe ser corto y directo, entre siete y diez oraciones con viñetas. Estas oraciones establecen claramente cómo las personas se comportan, se comunican, colaboran, apoyan, entregan y actúan juntas. También debe indicar lo que el equipo espera del negocio.

• Agile es tanto una mentalidad como principios y conceptos rectores. Te ayuda a desarrollar la forma en que te comportas, piensas, negocias, interactúas, comunicas, actúas y mejoras. Se basa en individuos motivados que se apoyan mutuamente para alcanzar un objetivo común, juntos como uno solo. Hay un proverbio africano:

A estas alturas, su equipo debería estar súper emocionado, energizado y motivado. Ahora, involúcrelos aún más con su acumulación de historias de usuarios.

Reserva

No tenga ninguna duda en su mente que hay incertidumbre involucrada en su proyecto. Es imposible saber exactamente lo que se necesita para crear el producto adecuado para sus clientes en una etapa tan temprana de su vida. No puedes mirar con nostalgia una bola de cristal y predecir el futuro.

El "backlog" o "backlog del producto" es donde residen sus requisitos. Agile favorece la redacción de declaraciones breves y concisas que capturen la esencia de un "requisito". El backlog es simplemente una larga lista de entradas, cada entrada define un "requisito" único y discreto como una historia de usuario. Y de ahora en adelante, usaremos la palabra historia de usuario y no "requisito". Probablemente te estés preguntando "¿por qué?" Buena pregunta. Durante lo que parece una eternidad, la declaración de las características o facetas necesarias en un proyecto de software por parte de un cliente siempre se ha considerado un requisito. Esa palabra tiene una interpretación que no tiene valor en Agile. El diccionario de Oxford lo define como:

Una cosa que se necesita o se desea. O, Una cosa que es obligatoria; una condición necesaria.

Y lamentablemente, si nos ponemos a definir cuál debe ser nuestra solución, afirmando que las cosas son “obligatorias”, terminaremos en un lío. Es demasiado fácil decir que todas estas historias de usuario son obligatorias. Si adoptamos ese punto de vista, corremos el riesgo de sobrepasar el cronograma y el presupuesto en el intento de entregar todo un alcance determinado. No es un problema decir que, para este producto, estas historias son necesarias para que la solución sea viable, solo queremos evitar la interpretación de esa palabra en particular.

• Siempre escribe historias desde la perspectiva de una persona. Una persona representa a un usuario o parte interesada de la solución. Es una buena idea desarrollar estas personas antes de iniciar una acumulación.
• En esta etapa, solo escriba declaraciones cortas y simples que básicamente sugieran un recordatorio para tener una conversación más profunda sobre la historia del usuario cuando sea el momento adecuado.
• Las personas reales piensan en términos de tareas que deben realizar para lograr un objetivo. Escribe tus historias desde la perspectiva de la persona y en términos de lo que necesitan hacer.
• No es necesario que escriba todo el backlog, solo escriba todo lo que pueda imaginar que sus clientes necesitarán para que su producto sea viable.
• Descubrirá más adelante a lo largo de la vida del producto que las historias de los usuarios cambiarán, se volverán más o menos importantes o se pueden eliminar por completo. Publicar con frecuencia, recibir comentarios y evaluar qué es una prioridad informará este comportamiento.
• No escribas historias de forma aislada. Involucre a su equipo, a las partes interesadas, incluso a sus clientes. Las historias se pueden actualizar en cualquier momento de la vida de un proyecto, pero se debe evitar que se cambien una vez que se haya iniciado el trabajo de desarrollo en ellas.
• Algunas de sus historias pueden considerarse “épicas”. Estas son historias grandes que cubren mucho y se desglosarán más cerca del momento de la entrega en historias más pequeñas.
• Considere usar el modelo INVEST, una lista de verificación para validar la calidad de una buena historia de usuario.
• Cualquiera puede agregar una historia a la cartera de pedidos. Debe colocarse en la parte inferior o en un "estacionamiento" especialmente creado. Esta historia adicional sirve como un indicador para discutir con el equipo y el negocio. Si el negocio y el equipo lo respaldan, se puede estimar y priorizar.
• También puede considerar aquellas partes del sistema que son más riesgosas. Si tiene una historia de usuario o una característica que es compleja, nueva o técnicamente desconocida, priorícelas en la parte superior de su cartera de pedidos. De esta manera, no intentará entregar las partes críticas y desafiantes de su producto solo unas semanas antes de su primer lanzamiento.

Una vez que tenga un backlog que satisfaga sus necesidades, puede estimar las historias que contiene, clasificarlas en orden de prioridad y crear un plan de publicación.

Estimación y priorización de alto nivel

La estimación de alto nivel es el proceso de dimensionar su cartera de pedidos. ¿Qué tan “grande” es el proyecto y qué valor ofrece? La priorización es el proceso de decidir qué historias son más importantes para usted, la viabilidad del producto y los intereses de sus clientes. Queremos entregar los artículos de mayor valor lo antes posible para brindar el mayor valor al negocio, obtener comentarios del cliente y no preocuparse por las cosas pequeñas. El resultado será un backlog ordenado clasificado en prioridad y dimensionado adecuadamente.

• Las historias en la parte superior se consideran las más valiosas. Queremos entregar los artículos más valiosos lo antes posible.
• Existen muchas técnicas para dimensionar y estimar, pero en este punto, solo desea obtener una buena idea indicativa del tamaño de una historia.
  • Utilice tallas de camiseta, tallas relativas, días ideales o puntos de la historia.
• Tampoco tendrá toda la información disponible en este punto, y está bien. Solo corre con eso.
• Involucre a las partes interesadas de su negocio o al gerente de producto, si tiene uno, y al equipo que hará el trabajo.
• Queremos que aquellos que estarán diseñando, desarrollando y probando el trabajo lo dimensionen, porque las mejores personas para estimar son los expertos.
• El equipo puede comenzar a dividir las historias en partes más pequeñas. Si esto sucede, escriba historias que sean más granulares pero discretas.
• El equipo también puede comenzar a clasificar algunas historias, ya que, naturalmente, algunas cosas deben entregarse antes que otras para respaldar la tecnología o el viaje de un usuario determinado.
• Entre usted y el equipo, también puede comenzar a encontrar vacíos en la cartera de pedidos que deben llenarse. Simplemente llene esos agujeros con nuevas historias y calcule y priorice según corresponda.
• La priorización se realiza más fácilmente utilizando un análisis MoSCoW. MoSCoW es una técnica simple que lo ayuda a decidir qué historias son "imprescindibles" para que su producto tenga éxito.
• Puede realizar un pase de priorización antes de que comience la estimación. Sin embargo, el dimensionamiento de ciertos elementos también puede determinar una decisión sobre la prioridad y el valor comercial real. Así que jueguen con la estimación y la priorización, ¡pero no se peleen por eso!
• No hay dos historias que puedan ser tan importantes como la otra. La historia en el rango 1 es más importante o valiosa que la historia en el rango 2.
• Una excelente manera de demostrar la importancia o el valor de una historia es agregarle un valor monetario. Si, por ejemplo, se cree que la historia A genera $5000 de ingresos adicionales y la historia B podría atraer $100, entonces la historia A es más valiosa. Del mismo modo, si la historia C salva al negocio más que la historia D, la historia C es más valiosa.
• Una vez que haya dimensionado su cartera de pedidos, se quedará con un número. When we come to release planning, that number will help us understand how much can be delivered by our team within a given timeframe.

Remember that you don't need to know all your user stories up front. Also, remember that it's not necessary to deliver all of your stories before a customer sees your product. You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

Release Planning

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

Adaptive Planning

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

Story Creation

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

Sprinting

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• Trabajar en pequeños incrementos tiene un gran beneficio. Significa que solo se está enfocando en el futuro inmediato de la entrega y, con nuevos aportes, comentarios y aprendizaje, puede responder al cambio dentro de un ciclo iterativo corto.
• Al comienzo de un lanzamiento, realice un sprint 0. Esto permite que el equipo, el negocio y el lanzamiento de su proyecto se preparen y establezcan la mentalidad para una entrega exitosa. Dibuje el marco técnico básico y la arquitectura que respaldarán la base para el lanzamiento. Configurar entornos, cuentas y herramientas. Realice picos para comprender problemas difíciles o desconocidos. Elabore sus historias de usuario en preparación para el sprint 1. El Sprint 0 se trata de prepararse.
• Durante un lanzamiento, siga refinando el backlog. A medida que comprenda más o aprenda algo nuevo, sus prioridades pueden cambiar, pueden desarrollarse nuevos requisitos y lo que antes pensaba que era una gran característica puede eliminarse por completo.
• No comience un trabajo que no tenga posibilidades de completarse en un sprint. Si no puede, divídalo en trozos más pequeños. Y no comience un nuevo trabajo cuando el trabajo iniciado anteriormente no se haya completado. No creas ningún valor al comenzar muchas cosas que no pueden considerarse completas. Además, evite el cambio de contexto. Esta es la actividad de comenzar una tarea, molestarse, comenzar otra y, en su forma más problemática, no completar ninguna de las dos.
• Limite la cantidad de trabajo que está en progreso por el equipo en un momento dado. Por ejemplo, si tiene tres desarrolladores y un probador, puede poner un límite WIP para los desarrolladores y el probador.
• Nunca agregue más trabajo a un sprint después de haberlo planificado. Nunca detengas un sprint a la mitad. Las excepciones a esto son:
  • Si se desempeñó más rápido de lo esperado, considere tomar la siguiente historia desde la parte superior de la cartera de pedidos, siempre que esté adecuadamente preparada.
  • Si el sprint está funcionando tan mal que no se completará. Por lo general, esto solo sucede cuando ha habido una catástrofe de alguna descripción.
  • Si el objetivo del sprint ya no se puede respaldar debido a las necesidades cambiantes inmediatas del negocio.
• Si cancela un sprint, hágalo con gracia, tómese el tiempo para reenfocarse y comience un nuevo sprint como lo haría con cualquier otro.
• Hacia el final de un lanzamiento, considere un sprint de lanzamiento final. No se escriben nuevas características, se pueden limpiar algunos errores y se pueden hacer preparativos para lanzar una nueva versión de su producto a sus clientes. Eso no quiere decir que no pueda hacer lanzamientos de clientes incrementales mientras tanto, es solo que se trata de un mecanismo de lanzamiento controlado, medido y sostenible.
• Al final de un lanzamiento, puede considerar un sprint de una semana. En este sprint, puede trabajar con el equipo para desglosar algunas ideas nuevas o descubrir alguna tecnología nueva. Estas son excelentes herramientas que benefician al negocio y le brindan al equipo un espacio de información para pensar y ser creativo. No es para perder el tiempo y seguirá creando valor. Igualmente, todo el mundo necesita un descanso. Tomarse unas vacaciones en este momento ayuda a mantener la cadencia y la velocidad en buena forma cuando estás a medio lanzamiento.

Definiendo Listo

Definir lo que realmente significa “hecho” es muy importante. Hay muchas versiones de "hecho" dentro de la vida de su proyecto: lo que significa estar "hecho" con una historia, lanzamiento o proyecto completo. Todo se reduce a lo que usted, su equipo y su negocio considerarán como completo con el nivel adecuado de calidad para satisfacer la preparación para el envío.

Para su equipo, la definición de una historia "terminada" será algo así como todo el código completo, revisado por pares, cumple con los criterios de aceptación definidos, probado por unidad, UAT y enviado a su repositorio de código. Para permitir el paso de una historia del diseñador al desarrollador y al probador, la siguiente persona en la cadena deberá aceptar las definiciones de "hecho". El propietario de su producto tendrá expectativas en cuanto a lo que esto significa para ellos con el fin de liberar el incremento del producto a sus clientes. En cualquier caso, todos deben ser conscientes de lo que significa “hecho” y ser parte responsable de que se cumpla su significado. Defina su definición de “hecho”, comuníquela, acuerde y evolucione. Hecho hecho.

Medición continua

Si no puedes medirlo, no puedes administrarlo. Lo mismo ocurre con las mejoras. ¡La necesidad de recopilar datos empíricos en un proyecto Agile es casi tan vital como la sangre que corre por tus venas! ¿Cómo sabe qué necesita gestionar, corregir o mejorar si no hay datos? Bueno, en pocas palabras, confiará en la intuición y las conjeturas sin fundamento, que se desmoronan bastante rápido bajo el escrutinio. Y dependiendo de quién esté haciendo el escrutinio, este puede ser un lugar bastante incómodo para estar. Entonces, desde el comienzo de su proyecto, asegúrese de saber cómo va a demostrar el progreso y con qué medidas otros verán su éxito.

Afortunadamente, Agile viene repleto de herramientas y técnicas útiles. Lo primero que debe hacer es volver al Manifiesto Ágil, escribir las siguientes palabras en su procesador de texto favorito, aumentarlas a 96 puntos, imprimirlas y aplicarlas en la pared para que todos las vean:

Su mayor poder demostrable en la entrega de software es mostrárselo a las personas que trabajan, haciendo lo que se supone que debe hacer. Esto no solo hará felices a sus clientes, sino que le dará a su equipo un gran respeto y engrasará las ruedas para una mayor adopción a través del negocio.

Aquí hay algunas otras herramientas:

• El standup diario: hay algunas variaciones de esta ceremonia, pero la esencia es que todos los miembros del equipo hablen entre sí cara a cara: manténgalo breve, enfocado y ligero. Si algo necesita una discusión extensa, estacione para una conversación más larga entre los que se necesitan después del standup. Si surgen impedimentos, escríbalos como una historia, agréguelos a su cartera de pedidos y hágalos frente lo antes posible. Cualquier cosa que esté obstaculizando a su equipo ralentiza su progreso y será demostrable a una velocidad reducida y un software que no cumple con las expectativas.
• Velocidad: Es una herramienta histórica. Es un poco como esas advertencias financieras que te dicen que el rendimiento pasado no es garantía del rendimiento futuro. Pero en el caso de Agile, esperamos lograr una velocidad de equipo que sea en gran medida fluida. Es la velocidad la que nos permite proyectar el desempeño futuro y la confianza en nuestros planes. Puede haber influencias fuera de su control que podrían reducir la cantidad de puntos de historia para un sprint determinado. Si esto sucede, probablemente podrá recuperarse. Nunca uses la velocidad como un palo para vencer a tu equipo; no le hará ganar ningún favor. Una cosa es segura: la velocidad será errática durante los primeros 2 a 4 sprints. Sin embargo, en algún momento de ese período de tiempo, debería comenzar a ver consistencia y estabilidad. Si su velocidad oscila de un extremo a otro, tiene un problema que deberá solucionar con su equipo.
• El gráfico de trabajo pendiente: Ahora bien, esta medida de progreso es espinosa. Por esa razón, no he proporcionado un enlace para obtener más información; tendrá que hacer su propia investigación y acordar como equipo y empresa cuál funciona para usted. ¿La razón por la que es espinoso? Bueno, ¡ningún recurso por ahí cuenta la misma historia! Una cosa acordada es que mostrará, dentro de un sprint o un lanzamiento, cómo se está desempeñando en comparación con su límite de tiempo. Si se mantiene diariamente, mostrará si está en el buen camino o si se está desviando. Algunos equipos lo usan para representar cuánto valor queda por crear, la mayoría de las veces, otros lo usan para mostrar cuánto trabajo queda por completar. El primero es una celebración del éxito y la generación de valor, el segundo es menos inspirador y motivador.
• El gráfico de trabajo pendiente: si debe mostrar las tasas de finalización del trabajo, use el gráfico de trabajo pendiente para eso. Pero el uso del gráfico de quemado le permite mostrar cuánto valor se ha creado y cuánto más valor está planeando crear al final del sprint. Una herramienta mucho más motivadora para que un equipo demuestre tanto al negocio lo que se ha hecho (o poco si las cosas no van tan bien…) como en lo que aún tienen la vista puesta. En cualquier caso, use los gráficos para detectar dónde el progreso no se está siguiendo como se esperaba y busque patrones o desviaciones y supervíselos para solucionar el problema subyacente lo antes posible. Actualícelos diariamente para los sprints y una vez al final de un sprint para los gráficos de versión de lanzamiento.
• Tableros de tareas: estos son excelentes radiadores visuales para demostrar el valor que se está creando. Cuando se actualizan diariamente, o en cualquier momento del día, muestran de inmediato el progreso que se está realizando. Si se combinan con Kanban, también son excelentes herramientas para visualizar el flujo y los bloqueos en el sistema. Si puede ver que se ha completado una gran cantidad de desarrollo, pero las pruebas no son tan productivas, puede ver que el problema está ocurriendo y responder de manera adecuada y rápida.

Otras herramientas a considerar son el valor ganado de Agile, el tiempo de ciclo y los diagramas de flujo acumulativo (CFD).

Mantenga estas medidas, gráficos y otras herramientas visibles, preferiblemente en voz alta y con orgullo en una pared para que todos las vean. El equipo, las partes interesadas y otras partes interesadas pueden ver de inmediato el estado de un proyecto. Es transparente y sirve como una valiosa herramienta de comunicación. Si no puede poner estos artefactos en una pared, use herramientas que se puedan compartir y colaborar, y asegúrese de que aquellos que quieran acceder lo tengan.

Mejora continua

A lo largo de su vida ágil, busque identificar y aprender dónde se pueden realizar mejoras. Las lecciones no se capturan ni se aprenden al final de un proyecto. Es como aprobar su examen de manejo y realizar tentativamente su primer manejo sin un instructor. Sabrá lo que funciona y lo que se supone que debe hacer, pero con el tiempo adaptará sus habilidades y capacidades de conducción, aprendiendo nuevas técnicas. Incluso adquirirás malos hábitos. Búscalos, entiéndelos y encuentra formas de mejorar.

Hay muchas oportunidades para identificar lo que no funciona y aplicar remedios. El enfoque incorporado a esto en Agile es la retrospectiva. Esta es la herramienta principal para la reflexión y el ajuste. Al final de cada sprint, tómese un tiempo con el equipo para mejorar la forma en que se realiza el trabajo, cómo se entrega la calidad, cómo se puede maximizar la eficiencia, cómo se puede minimizar el desperdicio y cómo se aumenta la capacidad. Cuando identifique medidas para mejorar, no caiga en la tentación de solucionar todos sus problemas de inmediato. Identifique los que tendrán más impacto y se pueden implementar en el próximo sprint. Medir y observar. Si tuvo el impacto deseado, ciérralo, escríbelo en tus formas de trabajar y definiciones de hecho. Si no funciona, piénsalo de nuevo. Cualquier lección aprendida que no se incluya en el próximo sprint se puede estacionar y priorizar para recibir atención en el próximo sprint.

Adaptar el proceso. Elimina todo lo que no funcione. Eliminar impedimentos. Su madurez como equipo Agile no tendrá límites si se lo permite.

Más allá de la gestión ágil de proyectos

Es importante saber qué sucede después de que se entrega el proyecto. El soporte y el mantenimiento son clave para garantizar que, una vez que el proyecto esté en manos de los clientes, siga funcionando; los comentarios de los clientes pueden tenerse en cuenta en versiones futuras; y los problemas de los clientes se tratan adecuadamente. Un proyecto es un esfuerzo único y limitado en el tiempo. El producto que entrega tiene una vida después de que el equipo del proyecto se haya disuelto. Asegúrese de que es capaz de admitir el producto una vez que esté activo.

Los proyectos ágiles coexisten con enfoques más tradicionales. Equilibrar los requisitos de control presupuestario y visibilidad de las partes interesadas con los objetivos ágiles de flexibilidad y capacidad de respuesta.

Se utiliza un marco de gobierno o un modelo de gobierno Agile junto con procesos Agile estándar, como Scrum. Funcionan de dos formas específicas:

• Proporcionan un envoltorio para un proyecto Agile al aclarar los procesos que ocurren fuera de las iteraciones de desarrollo (sprints). Esto incluye proporcionar criterios claros para la finalización exitosa del inicio del proyecto y la validación adecuada de las decisiones y el plan.
• Cambian el énfasis de partes específicas del proceso Agile estándar y resaltan principios y técnicas particulares que necesitan gobernanza o sustentan la gobernanza.

En el mundo en constante cambio de hoy, las organizaciones y las empresas están dispuestas a adoptar un enfoque más flexible para entregar proyectos y quieren volverse más ágiles. Sin embargo, para las organizaciones que ejecutan proyectos y programas, y donde ya existen procesos formales de gestión de proyectos, la informalidad de muchos de los enfoques ágiles es desalentadora y, a veces, se percibe como demasiado arriesgada. Estas organizaciones centradas en proyectos necesitan un enfoque ágil maduro: agilidad dentro del concepto de entrega de proyectos: gestión ágil de proyectos .

Aprenda y crezca con su adopción de Agile. Solo haga aquello con lo que su equipo se sienta cómodo, asegúrese de que se escuche su voz y actúe de acuerdo con sus solicitudes. Anime a su equipo a adoptar técnicas nuevas y más valiosas cuando sea el momento adecuado. Negociar con el negocio y animarlos a entender lo que significa ser una organización Agile.

Disfruta el viaje.