Conferencia Agile Spain 2016 3l5m31

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 , no solo navegaremos por las categorías para describir funcionalidades sino que profundizaremos en el proceso de captura de del y análisis de los datos de cara a decidir nuestra priorización y nuestro product roap. 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 de los s está por encima de los grandes gurús de producto que conocen lo que los s 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 es 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 s. 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 testing, 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

Despite the old fashioned business is focused on analysis rituals, today's technology is built under the light of experience. Thereby, requirement analysis approach and practices are evolving; only agile practices that involve BA and UX collaboration can create the efficient and satisfying experience for your product.

Business agility is creating a learning organization that is every time faster and better at learning about themselves and their customers. This talk is about understanding the key factors and leadership style required to nurture learning organizations in order to boost business agility.

El modelo DIAS surge como una nueva forma de visualizar las iniciativas dónde estamos involucrados en base al grado de autonomía de las mismas, olvidando los TODO-DOING-DONE y hablando de fases de relación. Me permite entender de primera mano qué tipo de liderazgo debo aplicar en cada situación de manera predominante y me marca los pasos para poder llevar las relaciones a otro punto. También de manera rápida puedo posicionarme en una fase u otra en mis conversaciones “seguimos en inmersión y necesito desarrollar un poco más esta habilidad para poder hacer XX solo”, “en la próxima sesión nos repartimos las dinámicas - Acompañamiento”, “he facilitado y necesito más formación y que me muestres más esta parte u otra - Inmersión”, “no tenemos claridad sobre la necesidad- no tenemos dirección- ni objetivo- Descubrimiento”. Es un modelo muy simple y natural, entendiendo de primera mano en qué consiste cada apartado y la necesidad de marcar una serie de pautas para la autonomía. Al ser un modelo de Relación, se realiza siempre entre dos partes involucradas, generando así diferentes vistas: PERSONA, EQUIPO, INICIATIVA (proyecto-producto), PORTFOLIO, que podemos emplear en los diferentes contextos de nuestro trabajo. En esta charla se ofrecerá a los asistentes las plantillas empleadas en el modelo y se mostrarán ejemplos prácticos de aplicación, así como tableros de uso y su aplicación en el cambio organizacional. Tanto si el formato es charla de 45 minutos o taller de 1 hora, se intentará sentar las bases para que los asistentes salgan de la sesión con la idea de cómo emplearlo en el ámbito de Persona, Equipo, Iniciativa, Portfolio.

As coaches, consultants, managers or engineers we have a tendency to fix problems by trying to understand what caused them, the root cause. Focusing on the problem. Problem focus is grounded in engineering and traditional psychotherapy models for fixing machines, processes or people. It works, specially for processes and systems, and there exist very powerful techniques like 5 WHYs, Ishikawa, Causal-Loop Diagrams in order to understand root cause. But, when we go into the domains of humans latest advances in working with individuals and groups have demonstrated that a positive approach to change, a focus on solutions, works much better than a problem-focus approach. From Positive Psychology, Brief Therapy and Solution Focus Coaching we have 3 different approaches to working with people in creating positive and durable change. In this talk we will see differences between a problem focus approach and a solution focus approach, we will understand the principles behind positive change, tools, techniques and real world examples that you can apply as Agile Coach, Manager or Team Member.

Back in the days I thought: Agile is just good marketing. A few tools, a bunch of buzzwords, what’s the big deal? In addition to that, I look at my past jobs as a software engineer and there was no Scrum, no Kanban, but it worked. Then I ed OptioPay, built up the IT department and for the first time it stopped working. We were growing as a company but I could feel things were going wrong, I could feel people being unhappy. But I did not possess the tools needed to fix it. As a consequence we brought in help from the outside and started an agile transformation in the beginning of 2016. I’d love to share our story. How we started, what steps we took when we moved to Scrum, the fears and doubts we had, the things we learned on the way, things that went completely wrong and of course all the amazing stuff that happened.

Test-Driven Development (TDD) has been so successful that it's now unfashionable. We seem to have lost the excitement and empowerment we felt when we first stumbled onto TDD a dozen years ago. Now it's just a chore that only bothers developers. Were we fooling ourselves, or did the message get confused along the way? In this talk, I will revisit the basics, the essence of what makes TDD work. I will look at some of the common difficulties that I see with teams that are struggling. I will show how TDD is as much an approach to development as a programming technique and how, like BDD, it's not about testing.

Are your agile ceremonies becoming boring and unengaging? Is the team doubting the value of these meetings? Let us show you how we at Typeform use techniques like gamification and visualization to spice up our meetings and keep the team engaged

El desarrollo de software implica aprendizaje constante. Trabajamos con tecnologías que apenas existían hace unos años y no pasa un día sin que aparezcan nuevas. Es un camino sin fin que puede tomarse por muchas vías, tan importante para los profesionales como para las empresas y al que no siempre le prestamos la atención necesaria. Cómo decidimos recorrerlo condiciona nuestro futuro como profesionales y la competitividad de nuestras empresas. Actualmente, en tiempos en los que parte de nuestro sector se cuestiona la utilidad de la universidad en nuestro aprendizaje a la vez que otra parte exige la necesidad de un título como reconocimiento de capacitación, si algo es incuestionable es que dejar de aprender no es una opción. ¿Qué podemos hacer los profesionales?¿Qué pueden hacer por nosotros nuestras empresas?¿Cómo deberíamos trazar nuestro camino? En esta charla profundizaremos sobre ello de la mano de Ronny y Modesto, dos viajeros cuyos caminos se juntaron en un evento de la comunidad.

Traditionally, business analysts have played the role of translators between the business and the technology worlds. Lean and agile earlier software practices focused on reducing the bottleneck in the development process. Later, frameworks like Scrum focused on how to organise teams in such environments. But the communication gap will not be removed if information goes back and forward from business to technology... Information may be flowing, but is communication really getting through? This talk will focus on how to overcome the lack of communication, define which best practices can help achieve a shared understanding and describe how to develop the loops required to ensure the alignment between business and IT that is so crucial yet so often overlooked.

Desde su aparición, a principios del nuevo milenio, las metodologías ágiles han difundido sus propuestas con mucho éxito, consolidando, a día de hoy, un puesto de vanguardia frente a los métodos tradicionales que durante años dominaron el sector de las tecnologías de información. Si bien estas prácticas ágiles nacieron en el ámbito del desarrollo de software, actualmente su influencia abarca también a otras disciplinas tecnológicas. En el marco de la gestión de los servicios TI (ITSM), conceptos como DevOps -para la istración ágil de sistemas- o la estrategia TI bimodal -propuesta por Gartner para el enfoque a dos velocidades- son tecnologías que en los últimos meses se han posicionado en lo más alto de las expectativas de los s. Esta ponencia presenta una aproximación a la implementación de un sistema de gestión de servicios basado en la norma internacional ISO 20000, haciendo uso de prácticas y técnicas ágiles. Apoyándose en la estrategia de las dos velocidades, se plantea un escenario en la que se identifican los procesos más proclives a ser implantados mediante métodos ágiles, y otros en los que, por su naturaleza, es más recomendable un enfoque más secuencial, como el modelo en cascada. Para ejemplificar la aplicación de estas prácticas ágiles en el contexto de la norma ISO 20000, se revisará el proceso Gestión de Problemas para mostrar la utilidad de las historias de s, los ciclos sprint y los tableros Kanban en el desarrollo y la ejecución del proceso.