¿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.
¿Qué es Polaris?
El norte que debe marcar el rumbo de los proyectos y dar respuesta a sus necesidades reales. Utiliza cuanto esté en tus manos, sin ataduras, más allá de los prejuicios, para alcanzar los objetivos.
Polaris es el resultado de años de experiencia desarrollando software para grandes compañías. No es dejar de ser ágil, es ser radicalmente ágil y adaptativo.
Manifiesto Polaris
01
Firmes en los principios Agile. Flexibles a la hora de adaptar el método a las necesidades de cada proyecto.
02
No nos limitamos a entregar software funcionando, sino además software bien hecho y que hace progresar un negocio. Nuestro éxito es hacer crecer a nuestros clientes.
03
Simplificamos al máximo para que las personas sean capaces de dar todo su potencial. Cada línea de código, cada post-it o cada reunión no se lleva a cabo si no aporta valor.
04
Somos personas, y nuestros clientes también, generamos un clima de trabajo integrador donde se escucha, se motiva y se coopera.
05
Comprometidos con el equipo y las necesidades del proyecto, por encima de roles e intereses individuales.
06
Nos servimos de nuestra experiencia para ir un paso por delante, anticipando los riesgos y mejorando la idea inicial del cliente.
07
Damos feedback con coraje y lo recibimos con madurez, buscando continuamente mejorar. Por eso si no se cumplen estos principios en tu proyecto, por favor, alza la voz
Los 9 elementos de Polaris.
-
True North
Agile soporta todos los cambios, tu cartera no.
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. -
Agile Delivery
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. -
Continuous Discovery
No eres un hámster en una rueda, todo proyecto requiere estrategia.
A un buen dueño del producto se le suelen pedir superpoderes. Solo con prácticas de diseño se puede crear un buen backlog, sino… Con una alta probabilidad, el resultado será algo que nadie necesite. -
Worthy Metrics
Métricas, no adverbios de cantidad.
Las métricas nos ofrecen visibilidad y transparencia. Son un nexo de unión entre negocio y tecnología y son capaces de centralizar la información relevante de diferentes herramientas de trabajo. -
Risk Focus
No hablar de riesgos, no los hace desaparecer.
Es evidente que el empirismo y la adaptabilidad minimizan los riesgos, pero no es suficiente. Poner foco en ellos en el día a día del proyecto puede marcar la diferencia. -
Adaptative Framework
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. -
Technical Quality
Que funcione no quiere decir que esté bien.
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.
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. -
Productive Mode
Los malos hábitos destruyen las mejores mentes.
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. -
Team Experience
No somos robots, ni queremos.
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.
Agile funciona, pero es insuficiente en un contexto cliente-proveedor.
Cristina de la Bandera
Desarrollo de negocio Agile
¿Por qué Polaris?
El problema no es lo que dice Agile, sino lo que no dice.
Durante los más de 15 años desarrollando software de forma ágil para grandes empresas, nos hemos dado cuenta de las necesidades reales de los proyectos, y lo que es más importante, qué aspectos están cubiertos por los métodos ágiles y cuáles hemos tenido que reforzar con prácticas propias para conseguir el éxito de estos proyectos.
No existen las balas de plata...por más que nos empeñemos, el mundo está lleno de excepciones.
Lamentablemente, intentar aplicar siempre la misma fórmula mágica solo provoca frustración y fracaso, ya que nunca va a funcionar si no se presta atención a las diferentes condiciones de entorno (tipo de relación contractual, reto, complejidad técnica, organización de equipos, etc.).
El agilismo se ha convertido en un fin en sí mismo.
La esencia se ha desvirtuado a base de construir toda una industria Agile alrededor, donde se endiosan los métodos y las prácticas por encima de los resultados y objetivos, y las certificaciones y formaciones por encima de las experiencias reales.
Qué no es Polaris.
No reinventamos la rueda.
No, no reinventamos nada. Ordenamos todo para que tenga sentido en base a nuestra experiencia. No hay por qué asustarse. Es puro Shu-Ha-Ri: nuestra experiencia nos lleva a rediseñar las reglas.
No es un volantazo al desarrollo tradicional.
Pero sí es entender que algunos elementos de una gestión tradicional pueden sernos útiles. Y que debemos hablar un idioma similar al de nuestros clientes. Pero sin palo y zanahoria y sin renunciar a nuestros valores.
No es un catálogo de herramientas.
No se trata de procedimentar herramientas, sino de compromiso y actitud hacia unos valores y un manifiesto. Tampoco es hacer un nuevo método con más eventos y artefactos; aprovechamos nuestra experiencia y cogemos lo que sabemos que funciona, con cabeza.
No es rebajar nuestro nivel.
No vamos a ser conformistas, ni menos disruptivos, no vamos a ser menos disciplinados ni a hacer lo que nos digan si no pensamos que es lo mejor para el proyecto. Es un acercamiento por vías diferentes a las actuales, poniendo foco en lo realmente importante para un proyecto.
No es otra movida agilista.
Esto no es un rebranding de Agile ni una vuelta de tuerca a los Scrum Masters. Es la experiencia real en primera persona de todos los círculos de conocimiento de Paradigma, encontrando juntos una mejor manera de trabajar.
Publicaciones
Cargando artículos…
¿Quieres sacar partido de nuestra experiencia gestionando proyectos ágiles en entornos reales?