¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.Agile soporta todos los cambios, tu cartera no.
Resultados sobre métodos.
No eres un hámster en una rueda, todo proyecto requiere estrategia.
Métricas, no adverbios de cantidad.
No hablar de riesgos, no los hace desaparecer.
No existen las balas de plata.
Que funcione no quiere decir que esté bien.
Los malos hábitos destruyen las mejores mentes.
No somos robots, ni queremos.
Agile soporta todos los cambios, tu cartera no.
Cogemos la inercia de las iteraciones y de las funcionalidades a corto plazo y perdemos el norte de hacia dónde nos dirigimos. En el momento en el que olvidas…
El True North nos hace levantar la cabeza del teclado para no perder el rumbo.
De un vistazo sabes, por qué estamos en el proyecto, cuáles son las líneas rojas y las claves de éxito, cómo pensamos llegar al objetivo y el avance del presupuesto.
La gestión de expectativas nunca fue tan fácil. Descarga aquí la plantilla y crea tu propio True North.
Descarga la plantilla de True North. (próximamente)
Resultados sobre métodos.
El objetivo no puede ser clavar el timing de los eventos, y calcar el framework de turno. Seguir un método al dedillo y que el proyecto vaya mal o algunas de las partes no esté satisfecha también es un fracaso.
Agrupamos las actitudes y habilidades que tantas veces han sido claves en nuestros proyectos bajo el nuevo rol del Agile Delivery Leader:
No eres un hámster en una rueda, todo proyecto requiere estrategia.
¿Has experimentado alguna vez el subidón de esas dinámicas multitudinarias de co-creación y conceptualización al inicio de un proyecto? En la mayoría de los casos son un mero espejismo, donde tecnología, negocio e incluso usuarios trabajaban juntos, pero que acaba desvaneciéndose mientras avanzamos por el desierto del desarrollo.
Es cierto que en los frameworks ágiles encontramos un rol encargado de evitar que esto pase, un dueño del producto, experto en el negocio, con poder de decisión, que mira al mercado, que conoce a los usuarios y tiene dedicación y disponibilidad total para el proyecto y el equipo de desarrollo... En definitiva, un unicornio.
Solo incluyendo prácticas de diseño se puede crear un buen backlog, si no, con una alta probabilidad el resultado será algo que nadie necesite.
Métricas, no adverbios de cantidad.
¿Te imaginas un mundo sin ...
Este mundo es posible si tenemos un sistema de métricas que ofrezca visibilidad y transparencia, que sea un nexo de unión entre negocio y tecnología, que esté centralizado, que lea la información relevante de las diferentes herramientas de trabajo (Jira, Azure DevOps, Sonar, Analytics, etc.) de la forma más automatizada posible y sobre todo que contenga las métricas específicas que requiere cada proyecto.
Si no miras una métrica, ¡elimínala!
No hablar de riesgos, no los hace desaparecer.
Es evidente que el empirismo y la adaptabilidad minimizan los riesgos, pero no es suficiente. Un gran grupo bancario, una energética internacional o el mayor retail del país, no van a dejar en manos del empirismo el éxito o fracaso de sus proyectos.
Si los riesgos no son más que situaciones inciertas que pueden dar lugar a nuevas oportunidades o amenazas para nuestro proyecto, ¿por qué no hablamos más de esto? ¿por qué parece algo pasado de moda? Poner foco en ellos en el día a día del proyecto puede marcar la diferencia.
¡Ojo! Que no va de tener una excel con riesgos levantados, eso es un “te lo dije...”, un cubrirse las espaldas. Necesitamos una nueva perspectiva de trabajo, sensibilidad con la realidad que rodea al proyecto, identificación y comunicación pero también proactividad, creatividad en las acciones de mitigación y constancia en su seguimiento.
No existen las balas de plata.
“Mi compañía es diferente” “Aquí es que las cosas funcionan de una manera particular” “Tal persona es que es un poco especial” “Este proyecto es estratégico, hay muchos ojos puestos en él”.
Oímos mil veces estas frases...y realmente todos somos diferentes, sin embargo, obviamos estas verdades cuando pensamos que podemos aplicar el mismo método como solución de facto.
Las personas, por naturaleza tratamos de buscar la piedra filosofal que solucione todos nuestros problemas, pero desgraciadamente, no funciona así. No prestar atención a las diferentes condiciones de entorno provoca frustración y fracaso:
En función de estas condiciones que rodean al proyecto ajustamos el método y creamos la versión más óptima para cada proyecto, aunque siempre sin traicionar nuestros principios.
Que funcione no quiere decir que esté bien.
“Cualquier idiota puede hacer código que compila, pero solo un buen programador puede hacer código que otros entiendan”. Martin Fowler
Un buen producto digital no es sólo usable y atractivo, debe ser mantenible, seguro, escalable, estable... La excelencia técnica es una garantía innegociable para evitar sobrecostes a futuro.
La tecnología, al igual que el método, debe estar al servicio de la necesidad, la simplificación/optimización de la arquitectura de software y tecnologías a utilizar y la automatización, nos permitirán ser eficientes en la construcción y operación del producto.
Por más reglas y buenas prácticas de ingeniería que se definan, la mejor apuesta es conseguir la responsabilidad compartida de todo el equipo sobre la calidad integrada.
Los malos hábitos destruyen las mejores mentes.
Las interrupciones y distracciones que nos rodean, la mala comunicación, el presencialismo sin sentido, el desorden y las tareas manuales, matan nuestra creatividad y nuestra concentración.
No hay método que soporte un equipo poco productivo, es “crónica de una muerte anunciada”. Por tanto, lo más inteligente es incorporar buenos hábitos de trabajo al propio método y facilitar su adopción en los proyectos:
No somos robots, ni queremos.
“Desde mi experiencia de más de 20 años en la tecnología, en diferentes empresas, proyectos y clientes, cuando hay problemas en los equipos, éstos no tienen que ver con la tecnología sino con las personas y sus relaciones". Andrés Macarrilla (Goodly)
La gestión de proyectos está a medio camino entre un arte y una ciencia, donde una de las partes más complicadas somos las personas.
Hacer que el principio de “Individuos e interacciones sobre procesos y herramientas” sea tangible y real, es una apuesta segura para que las cosas funcionen..
Y no es una acción puntual, es cuidar cada momento crucial de la vida del equipo, desde la composición del mismo basada en el Cultural Fit, pasando por la autogestión de conflictos y toma de decisiones, gestión de cambios en el equipo, hasta el desarrollo de competencias del comportamiento humano y la cultura del feedback.