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.

"A kata is a programming exercise which helps programmers hone their skills through practice and repetition"

I've done 2000 of them in 7 different languages, what have I learned? Am I really a better developer?

I'll talk about programming practices, language design and algorithm quizzes after spending countless hours solving and reviewing katas. I've suffered doing performance optimizations in numeric sieves or dealing with verbose languages when a python one-liner would do the same job. I've also struggled with simple programming exercises in Elixir or Haskell...

I think I've discovered a thing or two on how to be a better developer and I'm thrilled to share it. Don't miss this talk!

Quien mejor que el cliente para saber que es lo mejor de tu producto,… imagina que pudieras tener el cliente siempre cerca y obtener una información veraz de lo que espera de tu producto, que opciones son las más aceptadas y valoradas, como quiero utilizarlo, que funcionalidades no dan resultado… tú producto sería exitoso desde el primer momento.EDD expone un modelo de desarrollo de producto basado en experimentos: hipótesis, prueba, resultado, decisión, hipótesis….Durante la charla vamos a ver como llevar a cabo este proceso, que capacidades debe tener el equipo, que herramientas son útiles para el desarrollo de estás dinámicas, etc.

Nuestras arquitecturas de software reflejan las estructuras de comunicación de la organización que las produce, según la Ley de Conway. ¿qué impacto tiene esto durante una transformación, donde las estructuras cambian, y las culturas se enfrentan? En esta breve charla expondremos el problema, y las razones por las que vigilar esos pequeños campos de batalla muy de cerca.

Time to market es uno de esos anglicismos extendidos en el mundo empresarial. Una buena opción para acortar ese tiempo es contratar a un equipo *indie* que sepa lo que se hace para ayudar que la idea de negocio pase a ser un producto digital que se enfrente al mercado.

¿A qué nos referimos cuando hablamos de equipos *indie*? Para nosotros son equipos pequeños, con una cultura compartida y que no pretenden escalar a nivel humano. Esto es, que consideran un valor mantenerse pequeños.

No es lo mismo personas que trabajan juntas que personas que trabajan en equipo. Así lo han entendido algunas compañías como Stripe, que anunciaron este año que empezaban a hacer recruiting de equipos completos. Aunque en realidad tampoco sea nada nuevo, llevamos años viendo operaciones de acqui-hiring entre compañías tecnológicas