CAS 2017 (Conferencia Agile Spain)
La semana pasada asistí como voluntaria a la CAS 2017, la Conferencia Agile Spain 2017, como se deonominan ellos, la mayor y más importante conferencia sobre agilismo en España.
Me hacía especial ilusión porque, aunque en Valencia he coordinado los meetups de UX Academy, y he asistido a un montón de eventos (pagando entrada), me apetecía mucho vivir por dentro, desde la parte de la organización, un acontecimiento de tal tamaño.
Parte de nuestro equipo en plena faena #CAS2017 pic.twitter.com/0LQVDUMXhW
— CAS 2017 Sevilla (@confagilespain) 15 de noviembre de 2017
¿Y el resultado?
3 días de locura nonstop, recortando pegatinas, montando urnas, haciendo chapas, doblando camisetas, montando el welcome pack (750 mochilas con agendas, cuadernos, flyers, macetas, libros, spinners…), gestionando las salas, haciendo de guardarropa de abrigos, maletas y mochilas…
Todo ello rodeada de gente genial, y conociendo a muchas personas relacionadas con el sector.
Os dejo el vídeo resumen realizado por l@s super chic@s de Autentia:
¿Me ves en el vídeo? 😉
2 días completos, 4 tracks paralelas más 2 salas de talleres, y unas 750 personas entre ponentes, asistentes y organizadores. ¿Te apuntas al del año que viene? Yo si puedo si!
La II Guerra Mundial, Japón y su importancia en la UX
Últimamente he estado leyendo mucho sobre Lean, Agile, Scrum, Kaizen… Y bastantes términos y artículos mencionan Japón, viniendo en muchos casos relacionados con su rápido resurgimiento después de la destrucción que vivió durante la Segunda Guerra Mundial.
Por ejemplo, el framework Scrum fue creado por Ken Schwaber y Jeff Sutherland directamente después de la publicación de Ikujiro Nonaka e Hirotaka Takeuchi de «The New New Product Development Game» en 1986, en la Harvard Business Review (HBR).
Pues bien, Nonaka fue contratado por el gobierno japonés después de la Segunda Guerra Mundial para ayudar a analizar por qué perdieron la guerra.
Otro ejemplo más relacionado con la UX o Experiencia de Usuario es el caso de W. Edwards Deming y su sistema de medios para generar de forma sostenible y económica productos y servicios que satisfagan los requerimientos del cliente (¿te suena?)
William Edwards Deming
Como consecuencia de la II Guerra Mundial, Japón estaba muy dañado, y a pesar de diferentes cómites de los países aliados, no había grandes mejoras.
La situación era grave ya que no podía producir la suficiente comida para alimentar a la población, y no podían exportar bienes para ganar dinero para comprar alimentos, ya que la producción industrial era muy mala (patrimonio negativo).
El Dr. Deming (1900-1993), ingeniero y consultor de gestión estadounidense, fue invitado por el director ejecutivo de la a Unión de Científicos e Ingenieros Japoneses, JUSE (Japanese Union of Scientists and Engineers), Qenichi Qoyanagi, para que les diera a los investigadores, líderes empresarios e ingenieros, una serie de conferencias sobre métodos de control de calidad y sus teorías de gestión en agosto de 1950 en Tokyo (Hakone Convention Center).
En ellas animaba a los japoneses a producir con calidad, siguiendo el método de realizar una investigación y mirar a futuro para producir bienes que tuvieran mercado durante mucho tiempo. Al finalizar el verano, el mensaje había llegado a le gerencia de la mayoría de las grandes compañías, como Sony.
Muchos consideran que Deming fue una de las inspiraciones del milagro económico japonés de posguerra (1950 a 1960) al influenciar con sus ideas la forma de trabajar, entre ellas:
- Mejorar el diseño de los productos para mejorar el servicio
- Conseguir el mejor nivel uniforme de calidad de producto
- Mejorar las pruebas de productos en el lugar de trabajo y en los centros de investigación
- Aumentar las ventas gracias a los mercados secundarios (globales)
En resumen, el mensaje a los líderes japoneses fue que si invertían en calidad e investigación, la mejora en el diseño y la calidad, a la larga reduciría los gastos, al tiempo que aumentaría la productividad y la cuota de mercado.
Ciclo de Deming
Conseguir esta satisfacción del cliente se logra a través de 4 fases que permiten la mejora continua:
- Planificación
- Acción
- Inspección
- Adaptación
Esto se conoce como el ciclo de Deming, pero te cuento una anécdota. El ciclo, fue presentado en 1929, por otro estadista, Walter A. Shewart, mentor de Deming. De hecho Deming lo llamaba «Shewhart Cycle», pero al hacerse más famoso él, es más reconocido como ciclo de Deming.
Varios fabricantes japoneses aplicaron sus técnicas de mejora continua y experimentaron niveles de calidad y productividad desconocidos hasta el momento. Combinando el aumento de calidad junto con un coste reducido creó una nueva demanda internacional de productos japoneses.
Seguir leyendo «La II Guerra Mundial, Japón y su importancia en la UX»
La importancia de la Actitud
Hace años que vi este vídeo de Victor Küppers sobre la importancia que tienen las actitudes en el cambio personal, y al hilo de un email que he recibido de una persona de Recursos Humanos, lo he buscado en el blog, pensando que lo había comentado ya en alguna entrada. Como es uno de los que más me han gustado, voy a hablar de él.
Victor Küppers, nos da una charla magistral sobre el concepto de la actitud (minuto 1:29) en la que además de aprender vas a pasar un buen rato.
Estamos rodeados de personas serias, correctas y profesionales pero hay otras que generan una sensación de Ole, ole y ole!!
Las personas somos como bombillas, porque trasmitimos, bombillas con patas ya que nos movemos por la vida.
Y hay personas que van a 30.000 watios y otras que van fundidas.
Todos trasmitimos algo, pero hay veces que conocemos a alguien y decimos «Ole, ole y ole!! Vaya espectáculo!», pero hay otras que conocemos a alguien y al cabo de 3, 4 segundos, decimos: «Pues….»
Llámalo feeling, química… cómo quieras, pero trasmitimos sensaciones y captamos las sensaciones que nos trasmiten los demás.
Y es que hay una crisis espectacular de estado de ánimo.
Hay mucha gente que está desanimada, desbordada, desquiciada, hasta el coco de todo y eso hace que perdamos nuestra manera de ser.
Victor nos comenta que existe una fórmula para ver cuánto vale alguién como persona:
(C + H ) x A
La C son los conocimientos, la H, habilidad, la experiencia, pero la A, es la actitud.
Y ¿qué es lo importante de la fórmula?
Pues que la C suma, la H suma, pero la A multiplica.
La diferencia entre las personas increíbles no está ni en la C ni en la H, está en la A.
No son personas geniales porque sepan un montón o porque tienen mucha experiencia, sino por su manera de ser.
Todas las personas fantásticas tienen una manera de ser fantástica.
La C y la H son muy importantes, como dice Küppers, no hay nada peor que un inútil muy motivado… Pero no elegimos a la gente por sus conocimientos sino por su manera de ser y era una jefa brutal por su manera de ser.
Con los amigos es más fácil, ya que nadie elige sus amigos por curriculum, los elegimos por la manera de ser. A ti te aprecian por tu manera de ser.
Eventos en Scrum II
Seguimos hablando de los eventos en Scrum. En el anterior post hablé sobre el Sprint y el Sprint Planning. A continuación seguiré con Daily, Sprint Review y Sprint Retrospective.
3. Daily Scrum
Es un evento que se celebra cada día, de duración de 15 minutos, en el que el Development Team sincroniza las actividades y crea un plan para las próximas 24 horas. Lo ideal es que se haga siempre a la misma hora y en el mismo lugar para que todo el mundo lo recuerde de forma fácil
La Daily Scrum sirve para inspeccionar el progreso hacia el Sprint Goal y cómo avanza el progreso. Para ello, se inspecciona el trabajo realizado en el último día y se comenta el trabajo que se va a realizar ese día.
¿Cómo se realiza?
Durante la reunión, los miembros del Equipo de Desarrollo explican:
- ¿Qué hice ayer para ayudar al Developement Team a cumplir el Sprint Goal?
- ¿Qué voy a hacer hoy para ayudar al Development Team a cumplir con el Sprint Goal?
- ¿Veo algún impedimento que me impida a mí o al Developement Team a cumplir con el
Sprint Goal?
La Daily Scrum es una reunión clave para inspeccionar y adaptar.
La Daily Scrum optimiza la probabilidad de que el Development Team cumpla con el Sprint Goal, cumpliendo las siguientes funciones:
- Ayuda a que la comunicación sea más fluida entre los miembros del Team
- Se identifiquen impedimentos y se proceda a realizar las acciones necesarias para su eliminación
- Se detecten antes las desviaciones (si existen)
- Mejora el nivel de conocimiento de los miembros del equipo de lo que sucede diariamente
- Promueve la toma de decisiones de forma rápida
El Scrum Master se asegura de que el equipo de desarrollo tenga la reunión, pero es el Development Team el que es responsable de realizar la Daily.
Sprint Review
La Sprint Review (Revisión del Sprint) se lleva a cabo al final del Sprint con el objetivo de inspeccionar el incremento y adaptar el Product Backlog si es necesario. El Sprint Team y los stakeholders revisan lo que se ha hecho en el sprint y en función de eso y de cualquier cambio producido en el Product Backlog, se decide cuales son las siguientes acciones para optimizar el valor.
El objetivo es obtener retroalimentación y fomentar la colaboración.
Es una reunión de 4 horas de duración máxima para Sprint de un mes, asegurándose el Scrum Master de que tiene lugar y que los asistentes entiendan su propósito. Es el Product Owner el que inivita a los stakeholders que cree conveniente a participar.
Realidad Virtual y Diversidad Funcional
Ayer en Las Naves fue el primer encuentro de una serie de 3 que se van realizar en torno a la realidad virtual para abordar diferentes problemáticas o retos sociales a los que esta tecnología puede dar respuesta, organizados porCol·lab, en este caso sobre Realidad virtual y Diversidad Funcional.
Mesa redonda con ejemplos de cómo aplicar realidad virtual en casos de diversidad funcional, diálisis y autismo (TEA). 😍 de los proyectos! pic.twitter.com/obyDOePpxl
— SaraClip (@saraclip) 30 de octubre de 2017
Durante la primera parte del evento, César Mari Jefe de sección de la Oficina Municipal de Atención a la Diversidad (OMAD) nos expuso cifras sobre la evolución en la ciudad de Valencia de los casos de diversidad funcional, haciendo un repaso de los principales problemas que se encuentran por tipo de diversidad, y por área (educación, sanidad…).
Y es que las cifras asombran. De los 791.632 habitantes de Valencia, 120.767 presentan algún tipo de diversidad funcional (cifras de 2016).
Un 15,25% de la población de la ciudad de Valencia presenta algún tipo de diversidad funcional
El mayor grupo de personas se encuentra situado en la franja de 45-65 años, un 32,77%, personas que aun les quedan muchos años por delante, y cuya calidad de vida se ve afectada.
Marcos Fernandez, Director de ARTEC y profesor de la Universidad Politécnica de Valencia, quien lleva desde el año 92 trabajando en desarrollar aplicaciones de realidad virtual, dio un repaso a la evolución de la tecnología, resaltando sabiamente que hay que lo complicado es entender para qué podemos usar estas tecnologías.
La tecnología es si, no resuelve problemas. Es una herramienta que hay que saber usar.
Posteriormente hubo una mesa redonda con Elena Olmo, coordinadora de NeuroEducation en LENI Lab (@LabLENI) de la Universidad Politécnica de Valencia, Borja Pérez, Doctor en Fisioterapia, y 2 integrantes de la compañía Nesplora (Maite, psicóloga y Marco, comercial) quienes explicaron sus diferentes proyectos y comentaron varios aspectos y limitaciones de estas tecnologías.
Eventos en Scrum I
Los eventos se usan en Scrum para crear un patrón constante y minimizar la necesidad de reuniones no definidas.
Todos los eventos son «time boxeados», es decir, tienen una duración máxima, pudiendo acabarse, siempre que se logre el objetivo del evento.
La idea es evitar el desperdicio de tiempo
El Sprint es un evento «contenedor«para todos los demás eventos, siendo cada uno de ellos una oportunidad formal para inspeccionar y adaptar algo. Y es que los creadores de Scrum,Jeff Sutherland y Ken Schwaber, diseñaron estos eventos para conseguir la máxima transparencia e inspección.
Existen 5 eventos diferentes:
- Sprint
- Sprint Planning, o Planificación del Sprint en castellano
- Daily Scrum, normalmente llamada Daily
- Sprint Review, o Revisión del Sprint
- Sprint Retrospective, o Retrospectiva del Sprint
He estado en algunas empresas que unifican Sprint Planning con Sprint Review, llamándo al evento «Syncro» o «Planificación» (adaptan Scrum a lo que han visto que mejor le funciona).
1. El Sprint
El Sprint es la base del Scrum. Es un periodo de tiempo de 1 mes, 3 o 2 semanas, durante el cual se crea un incremento de producto, utilizable y potencialmente liberable. Lo ideal es que siempre tengan la misma duración.
Para entender el párrafo anterior, debemos ver cada Sprint como un proyecto con un horizonte no mayor a un mes. Y al igual que un proyecto, el Sprint se utiliza para lograr algo. Cada Sprint tiene una definición de lo que se va a desarrollar, un diseño y un plan flexible que guiará su construcción, el trabajo y el producto resultante.
Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior.
Un sprint está formado por el Sprint Planning, las Daily Scrums, el trabajo de desarrollo, Sprint Review y Sprint Retrospective.
Consideraciones a tener en cuenta durante el Sprint
- No se realizan modificaciones que pongan en peligro el Sprint Goal.
- Los objetivos de calidad no disminuyen.
- El alcance (scope) puede ser clarificado y renegociado entre el Product Owner y el Developmente Team a medida que se descubren las cosas.
La limitación máxima de un mes es para minimizar riesgo y desperdicio. Si es más tiempo, en el mundo tan cambiante en el que estamos, la definición de lo que se está construyendo puede quedarse obsoleta, aumentando además la complejidad de lo creado.
Product Manager
He estado trabajando bastante tiempo con empresas tecnológicas. En cada una tenía un nombre diferente, pero con el tiempo y hablando con la gente me he dado cuenta que se pueden aglutinar bajo uno solo: Product Manager.
Y es que uno de mis principios desde que realicé la carrera de Diseño, ha sido crear productos que la gente adore: bonitos, funcionales y usables, y sean sostenibles para la empresa.
Porque para construir un buen producto o servicio digital, el equipo o persona encargado de su Road Map, debe tener un conocimiento mixto de negocio, tecnología y experiencia del usuario (UX).
Aunque como es imposible saber de todo, debe ser experto en al menos uno (en mi caso UX), ser apasionado por los 3 y haber trabajado en los 3 en general.
- Negocio: no hay que olvidar que alguien tiene que pagar la fiesta. El Product Manager se centra en la optimización de un producto para alcanzar los objetivos comerciales mientras se maximiza el retorno de la inversión.
- Tecnología: es muy complicado definir qué construir si se desconoce como se va a hacer y más importante, los recursos requeridos.
- Experiencia del usuario: el Product Manager es la voz del usuario dentro de la empresa: debe hablar constantemente con los usuarios, testear el producto, analizar datos, detectar y priorizar los problemas a solucionar…. .
Funciones del Product Manager
Se debe establecer una visión del producto, investigando constantemente el mercado (informes de investigación, tendencias…), los usuarios (comentarios, atención al cliente, investigación etnográfica…) y el problema a resolver (mapas de empatía, customer journeys, análisis cuantitativo y cualitativo…).
Esa visión debe ser conocida por todo el equipo.
Si se realiza bien, cada miembro del equipo, desde ventas hasta desarrolladores, debe ayudar a crearla y sentirse parte de ella. Todos deben remar en la misma dirección.
Una parte importante es el establecimiento de las prioridades a desarrollar, el Road Map, el cual no es un documento definitivo, sino que puede variar dependiendo de la investigación que se vaya haciendo (recuerda que estamos en un mundo de constante cambio y es imposible predecir nada a futuro).
Ley de Little
La ley de Little (por la primera persona que la enunció John Little, 1954), conocida como Teoría de colas o Líneas de espera, usada para calcular el rendimiento de los sistemas ofrece múltiples aplicaciones.
La ley enuncia lo siguiente: el número medio de usuarios «N» que hay en un sistema (durante un tiempo determinado) es igual a la velocidad media «V» a la que entran en el sistema multiplicada por el tiempo medio «T» que están dentro.
N = V × T.
Aunque parece intuitivamente fácil, hay que destacar que la relación no está influenciada por la distribución del orden de llegada, cómo se atiende a los usuarios o prácticamente cualquier otra cosa.
Visualización de tareas en un sistema mediante Jira
Por ello se puede aplicar a cualquier sistema que procese cosas, y a sistemas dentro de otros sistemas. Los únicos requisitos son que el sistema sea estable y no preventivo.
Es usada en sistemas informáticos, para calcular plazos de entrega de trabajos o pedidos, para saber cuanto tiempo un cliente tiene que esperar a ser atendido en una caja de un supermercado…
Ley de little en la gestión del trabajo
Yo descubrí esta ley oyendo un vídeo sobre Kanban de Jerónimo Palacios en la Coferencia Agile Spain 2016 hablando sobre la relacion directa entre nuestro lifetime, el trabajo existente en curso y la capacidad de entrega. De ahi me puse a aprender un poco más sus aplicaciones.
¿Cómo nos ayuda el método Kanban?
Kanban es un método de gestión de trabajo ideado para mejorar el proceso de fabricación de Toyota, basado en señales visuales (Kanban significa en japonés “señal visual” o “tarjeta”.)
Y es que una imagen vale más que mil palabras, ya que se ha descubierto que el cerebro procesa información visual 60.000 veces más rápido que texto.
La información visual comprende el 90% de los datos que llegan a nuestro cerebro, estando el 40% de todas las fibras nerviosas conectadas al cerebro relacionadas con la retina.
Visualiza el trabajo
Kanban ayuda a aprovechar el poder de la información visual para crear un modelo visual del trabajo y su flujo por los estados que atraviesa.
Ver los diferentes estados por los que atraviesa el trabajo dentro del proceso de un equipo, como fluyen las diferentes tareas, permite, no solo comunicar el estado, sino también dar y recibir contexto para el trabajo.
Imagen extraida de www.leankit.com
Kanban ayuda a trasladar la información que normalmente se comunicaría a través de palabras a un formato más visual, permitiendo focalizarte además sobre los datos importantes.
Mirando el tablero, una persona conoce rápidamente como funciona el sistema y en que estado se encuentra.
Al observar visualmente el flujo de trabajo moviéndose en el sistema Kanban, es fácil detectar tareas que bloquean, cuellos de botella, colas, permitiendo servir como punto de partida para generar una conversación lo que lleva a una mejor comunicación y colaboración.
Limita el trabajo en proceso
Limitando la cantidad de trabajo pendiente en proceso, se puede reducir el tiempo que le toma a un elemento fluir a través de los estados.
En las empresas se cree que trabajar sobre varias tareas en paralelo aumenta la productividad, asignándose varias tareas a una misma persona. Pero eso no es verdad, las multi-tareas retrasan en lugarde acelerar la terminación de trabajo. Seguir leyendo «¿Cómo nos ayuda el método Kanban?»
Kanban
Kanban es un método que muestra como el trabajo se desarrolla.
Kanban es un método de gestión del trabajo, no de personas.
Permite que se tenga un entendimiento compartido del trabajo realizado, incluyendo las reglas por las cuales se efectúa el trabajo, cuántas tareas se pueden manejar en un determinado periodo de tiempo y como regularmente se entrega algo acabado a los clientes ya sean internos o externos.
El objetivo es que una vez que se llega a este entendimiento se pueda empezar a mejorar.
Sabremos predecir mejor como funciona el equipo (o nosotros mismos) y trabajar a un ritmo más sostenible. Se incrementa la colaboración y la comunicación, lo que consigue productos de mayor calidad. La empresa entera se alinea, consiguiendo realizar objetivos estratégicos.
Imagen de Jira, programa de Atlassian usado para visualizar el estado del trabajo
Las personas llegan a ser más independientes porque desarrollan una comprensión innata del riesgo que conlleva la gestión. Kanban consigue que la gente adquiera compromiso y un conocimiento del flujo de trabajo, lo que lleva a aumentar la agilidad.