Conferencia Agile Spain 2016 Autentia

Si quieres ver el vídeo con slides: https://www.youtube.com/watch?v=2K-pAkCuR-c

"Todo Scrum Máster comienza cargado de ilusión, sin embargo es habitual que esta fuerza se diluya por la rutina, la falta de apoyo o la falta de tiempo... Esto nos lleva a caer en ciertos Vicios, en forma de malas prácticas. Las Virtudes en cambio nos otorgan la posibilidad de seguir motivando el cambio. ¿Eres una Scrum Mom? ¿Te has olvidado que esto también puede ser divertido?... Esta presentación trata de reducir Vicios y fomentar Virtudes. Vuelve a ser un líder, tu equipo lo agradecerá."

In agile, we always talk about teams, quit barriers, group workforce, and other big buzzwords, but when we focus on product ownership, we focus on a given isolated role. The product is build by a team. Why not build teamownership, rather than focusing all on a given role. Product Success = TEAM.

El modelo de Kano es el gran desconocido de las técnicas de priorización de producto. Con una fuerte orientación hacia el usuario, no solo navegaremos por las categorías para describir funcionalidades sino que profundizaremos en el proceso de captura de feedback del usuario y análisis de los datos de cara a decidir nuestra priorización y nuestro product roadmap.
Aún habiendo sido creado en los años 80, el modelo de Kano se erige como un método estructurado de priorización, como parte esencial para organizaciones del siglo 21, donde la habilidad de experimentar rápidamente y analizar el feedback de los usuarios está por encima de los grandes gurús de producto que conocen lo que los usuarios quieren.

Vivimos una época de cambio en la que muchas organizaciones se han decidido a dar el salto para transformarse digital y culturalmente, con el objetivo de ser más flexibles y de poder ser más rápidas en su toma de decisiones, y así poder dar respuesta a un mercado cada vez más cambiante y competitivo.

Dentro de la organización existen muchos procesos Core que afectan al día a día, siendo uno de los mas importantes el proceso de financiación y presupuestario para Productos, Proyectos y Equipos, y difícilmente podremos generar un cambio duradero en una organización si a nivel presupuestario seguimos utilizando procesos tradicionales poco flexibles y no alineados a las nuevas filosofías de trabajo.

El objetivo de la ponencia es presentar un modelo de Agile Budgeting que permita a las organizaciones pasar de un proceso basado en centros de coste, financiación de requerimientos y en la asignación de personas al trabajo, a un modelo basado en el mindset Lean-Agile donde trabajemos con equipos estables y asegurando que la flexibilidad y la toma rápida de decisiones es soportada por los procesos financieros y presupuestarios de la organización.

El viaje empezó con una necesidad de formación en gestión de proyectos. En lugar de plantear una formación estándar, todo el Departamento participó en un Project Management Improvement Workshop, donde el objetivo fue que todo el personal dibujara conjuntamente su propio escenario ideal después de ver diferentes modelos y analizar los pros y contras. Con este enfoque bottom-up, se creó una hoja de ruta hacia un modelo ágil empezando por un piloto y una redefinición de roles. Los equipos empezaron a trabajar por Sprints, con una persona centrada en el rol de Product Owner por cada equipo. Algunas unas herramientas de gestión se sustituyeron por paneles Kanban en las paredes de los despachos y salas de reuniones. En las primeras retrospectivas se constató que el modelo había mejorado los tiempos de entrega y la sensación de aportar más valor a los usuarios. Si quieres aprender más detalles acerca de la evolución de un modelo de gestión tradicional a un modelo ágil en equipos que trabajan con tecnologías tan diferentes como SAP, Salesforce o .NET, esta es tu sesión.

Traditional hardware development workflows often take months or even years until the first prototypes are ready. On the other hand in software development we often try to test out new features every few weeks or even just after a few days.
There are more and more projects in which these two approaches collide and result in delays and overall frustration.

Getting some early prototypes can be essential to do user testing, verify assumptions and define the interface between the hardware and software parts. This talk will give an overview of a few different kinds of prototypes, which ones you might need and how you can start building them.