El corazón de scrum (Adelanto #1 de “Por un scrum popular”)

by

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

El corazón de scrum

Cuanto más enseño y brindo consultoría sobre scrum, más me convenzo de que el tablero físico es el corazón de scrum. Sin el tablero el equipo carece de centro, de foco. El tablero, si realmente se lo entiende, se convierte en el hogar espiritual del equipo. Una especie de iglesia, si les gusta la analogía. Los miembros del equipo se reúnen alrededor del tablero para discutir, pelear, innovar, alinearse, corregirse unos a otros, aprender y celebrar.

El tablero (conocido también como taskboard), con sus fichas, post-its, cintas y banderas, inspira colaboración. Es visual, táctil, enorme. Se yergue como un gran comunicador de nuestro progreso y carácter. Proclama a los cuatro vientos quiénes somos como equipo. Es nuestra identidad. El tablero no calla la verdad, sino que la difunde: no tenemos miedo.

Al tablero se lo describe muchas veces como la máquina de café del nuevo paradigma. Este paralelo, aunque bien intencionado, no hace más que subestimar el poder y el significado del tablero. Claro, es un lugar donde nos encontramos a charlar. Pero no, no es un lugar donde nos quejamos, repetimos chismes ni vomitamos odios. El tablero es un sitio para regenerarse, para reconectar, para tomar aire. Representa avance, no huida.

Scrum es la antítesis de la mentalidad dividir-y-conquistar propia del cubículo corporativo. No necesitamos mesas de ping-pong y futbolines para calmarnos, para crear un equilibrio artificial entre la vida y el trabajo. No necesitamos que la diversión sea algo que solamente puede suceder al salir de la oficina. Trabajar es divertido. No necesitamos ratos al lado de la máquina de café y pausas fumando para poner en práctica una de las más profundas necesidades humanas, como lo es la conversación espontánea, honesta. En scrum vivimos conversando, todos los días, todo el día.

En scrum nos importa profundamente la gente, no su conocimiento. No hablamos en singular, sino siempre en plural. No soy ‘yo’, somos ‘nosotros’. Compartimos, aprendemos, mejoramos continuamente, interactuamos, colaboramos apasionadamente y crecemos como individuos. Formamos tribus, construimos comunidad. Los miembros de una tribu necesitan un sentido de pertenencia, una aventura. Las tribus necesitan lugares de encuentro, objetos sagrados, foco y pulso. En scrum queremos que florezca este modo de ser. El tablero y todo lo que surge a su alrededor bombean vida.

Para vivir plenamente scrum necesita un corazón. Ese corazón es el tablero. Sin un tablero scrum se ve y siente insípido, escuálido, debilucho. Se pierde todo foco y sin un controlador externo, como ser un coach, que le insufle vida permanentemente, todo el esfuerzo que hemos puesto se disolverá, para convertirse subrepticiamente y sin cambiar enteramente sus formas en el proceso disfuncional que vino a reemplazar. Sin corazón, scrum es impotente.

Una de las acciones más generosas que un scrum master puede hacer por su equipo y por la organización es crear transparencia, irradiar información. La transparencia nos permite ver los errores, para así poder decidir si queremos hacer algo al respecto. Podemos dejar de ser víctimas del proceso para convertirnos en guerreros del cambio.

Si los equipos realmente comienzan a adueñarse de sus tableros y descubren cómo utilizarlos para vivir a pleno el principio de transparencia, este humilde collage de papelitos y cinta se elevará por encima del injusto estatus que ha ganado de objeto meramente utilitario. Cada equipo es capaz de lograr que su tablero pase a ser no solo una herramienta útil sino también un objeto bello e inspirador. Creo sinceramente que ese es el lugar que el tablero merece ocupar. El corazón se nutre de amor.

3 de agosto de 2009

Anexo tendencioso: un palpitar genuino

Si bien concuerdo con la importancia que tiene el tablero a la hora de moldear el imaginario del equipo, creo firmemente que el corazón de scrum está ubicado en otra parte de su ágil cuerpo. Mi sensación es que la retrospectiva es sin duda quien dará la energía que necesita un cambio de la magnitud que merece una implementación genuina de scrum. El tablero insufla un impulso inicial, colorido y terrenal. La retrospectiva permite seguir avanzando con scrum, explorando nuevos y peligrosos territorios, pase lo que pase, caiga quien caiga.

La experiencia me muestra que la importancia de la retrospectiva puede entenderse por oposición: cuando no la practicamos (o lo hacemos de formas poco efectivas) todo, en el fondo, sigue igual que antes. No hay reinvención, y sin reinvención no hay vida.

El proceso, la forma en la que trabajamos, es un músculo. Hasta el más escéptico de los sedentarios entiende que los músculos, si no se los ejercita, se atrofian. Necesitamos esforzarnos, llevar sanamente al límite tendones y tensores, si queremos que nuestros músculos se mantengan, al menos, con la energía y tono que tienen hoy en día. Lo mismo, exactamente lo mismo, ocurre con nuestro proceso. Si dejamos que el tiempo y la indiferencia se ocupen de mantenerlo en forma, si pensamos que la mejor manera de trabajar ya fue decidida y no vale la pena retocarla, entonces vamos a acumular grasa subrepticia e indefectiblemente. Tal vez la aorta de nuestra organización tolere tanto lípido durante años y años. O tal vez no.

Por un scrum popular – una variación lingüística

by

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Hace ya casi un año que Tobias Mayer publicó su primer libro, armado como una colección delicadamente curada de posts de su autoría. Desde un principio supe que The people’s scrum, título por si solo desafiante, tenía que tener su versión en español.

Con Tobias mantenemos una gran amistad desde hace varios años y colaborar en esto fue algo obvio, necesario, natural y, claro, no exento de conflictos. “Traducción” sonaba a poco, así que nos decidimos por algo que denominamos, sin muchas precisiones, una “Variación lingüística”.

El resultado fue una traducción mucho más literal de lo que me esperaba, con algunas libertades que decidí tomarme (sobre todo agregando adjetivos que brinden un poco más de lirismo). Ahora, al leer y traducir sentía que quería decir algo, proponer, discutir, festejar. El resultado fueron una serie de “anexos tendenciosos”. Luego de la gran mayoría de los ensayos comenté, me opuse, critiqué, precisé, repetí, expandí y celebré.

Estamos en la etapa final de edición del libro (¿faltará un mes más o menos?), pero con Tobias queríamos ir dándoles unos adelantos de lo que se viene. En los próximos días voy a estar posteando algunos ensayos con su correspondiente anexo tendencioso. Habrá alguno más orientado a criticar la manera en la que muchos entienden la agilidad y otros tantos con foco en cuestiones muy precisas del framework.

Eso sí, no lo duden, scrum ahora se escribe con minúscula. A leer y actuar en consecuencia, que se acaba el mundo.

Scrum teams: self-organizing or self-directed?

by

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Recently I am facing discussions too frequently with different people about the meaning of a self-organizing team in SCRUM. I think there are some misunderstandings between self-organizing and self-directed teams. Let’s see… a self-organized team follows a goal ( that might or might not be shared ) defined by the P.O. and her stakeholders. The team decides HOW they want to face the challenge of building the product that has been already defined: They arrange their processes, they decide who does what, technologies, tools, etc… They decide all that matters to them. The team focus is only on “BUILD THE THING RIGHT”.

In a self-directed team, the members are also stakeholders, meaning, they also discuss WHAT we are going to do with the Product Owner and the rest of the stakeholders. The team focus is at the same time “BUILD THE THING RIGHT” and “BUILD THE RIGHT THING”.
Being at the same time a development team member and a stakeholder is extremely powerful since the team alignment is actually organic: We are building the product we have shaped. The risks of demotivated, disengaged team members are quite mitigated. However, this situation cannot always be achieved.

To practice SCRUM, you don’t actually need to setup self-directed teams, although it would be great to have. Don’t hesitate if you have the chance to have a self-directed team, there are only benefits from it.

Let’s consider different scenarios:

A team in a consulting company developing a product for a client
The development team members are hardly going to become stakeholders. Nonetheless, they can come up with ideas, and it’s up to the P.O. to handle this according to the current situation. But the chances that development team members have a considerable impact on the backlog are prettly low. It’s definitely unusual to find self-directed teams in this environment.

A different scenario could be a team building a video game
One of the best games you can play in Facebook and mobile, papa pear saga, is actually composed by a self-directed team. In this team, it’s normal to have business organize team discussions about the new characters, new boosters, new blockers, special campaigns, etc… Roughly everything the Product Owner wants to kick into a sprint is in one way or another co-created by the team.

Que es un Agile coach?

by

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Un agile coach es el profesional que se encarga de que una organización progrese en su implantación de métodos Agiles independientemente del punto en el que se encuentre. Y esto puede ser desde estimular el interés en una organización que nunca antes escucho hablar de Agile, hasta mejorar la ejecución de las técnicas y métodos ágiles en una implementación ya madura, pasando por guiar la completa transformación a Agile de una empresa fundamentada en métodos tradicionales.

 

Aunque muchos piensan que el termino ‘Agile coach” no es mas que una forma mas moderna y llamativa de referirse a un consultor de toda la vida, bajo mi entender son dos perfiles extremadamente diferentes tanto en su objetivo como en las capacidades que ofrece.

Un consultor tradicional normalmente aconseja y propone soluciones a su cliente basándose en su experiencia anterior. Por lo contrario, un agile coach entiende en que situación se encuentra su Coachee y prepara un camino de evolución desde su situación actual a una futura, mas cercana a sus objetivos bajo los principios, valores y métodos Agiles. Además, le acompaña durante este recorrido ayudándolo a identificar y mitigar, o eliminar, las barreras que encuentre en su camino.

Para que un Agile Coach pueda llevar a cabo esta misión con éxito, debe contar con una serie de capacidades que podemos ver esquematizadas en el framework de competencias que proponen Lyssa Adkins y Michel Spaid:

 

En este articulo, voy a hacer un breve recorrido por las áreas de este marco de competencias. Y aportaré mi visión sobre como creo que un Agile coach debería ser capaz de cubrirlas para cumplir con las expectativas de su cliente.

Agile / Lean Practitioner:

Quizá esta sea la mas intuitiva de las capacidades que se esperan en un Agile coach, evidentemente un Agile coach tiene que saber de Agile y haberlo puesto en practica. La formación y la lectura son condición necesaria para comprender los conceptos, principios y valores ágiles. Además de esto, es critico que el coach haya implementado Agile desde las trincheras y experimentado en sus propias carnes la evolución del aprendizaje, las dudas, las incógnitas, los miedos y todos aquellos impedimentos por los que pasa un Agilista desde que comienza a investigar sobre agile hasta que se convierte en practicante experimentado. Solo mediante la practica en el campo de batalla será capaz de entender el espíritu de Agile y ayudar a otros a sacar el máximo partido de este paradigma.

Trainer: 

La mayoría de las implementaciones o transformaciones a métodos ágiles incluyen (o deberían incluir) una importante inversión en formación no solo durante el periodo inicial sino a lo largo todo el recorrido  de mejora. Por esto es fundamental que el coach cuente con capacidades de formador y herramientas de entrenamiento adecuadas, que le permitan desarrollar las capacidades necesarias en los futuros Agilistas de la organización para la que esta trabajando.

 

Mentor:

“Hacer Mentoring consiste en apoyar e incentivar a la gente para que manejen su propio aprendizaje en modo que maximicen su potencial, desarrollen sus capacidades, mejoren su rendimiento y se conviertan en la persona que quieren ser.” Eric Parsloe “Oxford School of coaching & mentoring.

El Mentoring es una potente herramienta de desarrollo en la que la misión del mentor no es dar respuestas deterministas a los problemas del “Mentee”, entre otras cosas, porque cuando hablamos de sistemas complejos estas no existen.

La relación Mentor – “Mentee” es un “partnership” entre dos personas que comparten experiencias similares. En el que el Mentor es un guía que utiliza sus experiencias, similares a la situación actual por la que pasa el “Mentee”, para ganar empatía y entendimiento sobre los problemas, dudas y dificultades de este. De esta forma el “Mentee” cuenta con apoyo y referencia adicionales para tomar las riendas del cambio que quiere construir.

 

Facilitador:

En Agile valoramos las personas y sus interacciones por encima de los procesos y las herramientas. Por esto exploramos formas de potenciar y sacar el máximo partido de las interacciones humanas. Para ello el Agile coach, entre otros roles como scrum master por ejemplo, debe contar con potentes herramientas y capacidades de facilitación de reuniones, ceremonias y encuentros. Así logrará que al trabajar con un grupo de personas ocurran con éxito las interacciones y la inteligencia colectiva que se esperan de un equipo Agil. De esta forma el equipo sacara el máximo partido del evento facilitado. Esto puede ser desde identificar las acciones de mejora que mayor retorno de inversión tengan después de una retrospectiva, hasta llegar a un acuerdo sobre la visión, condicionantes y alcance de un proyecto después de un evento de iniciación de un proyecto (o Inception).

 

Coach:

Quizá este sea uno de los aspectos mas controvertidos a la hora de describir un agile coach.

Significa esto que para ser Agile coach debo haber recibido formación especifica de Coaching? Son los Agile coaches psicólogos o algo parecido? (Nota importante: un psicólogo y un Coach se parece como una historia de usuario a un caso de uso, y como una lámpara a una mampara)

Hay opiniones de todos los tipos respecto a este aspecto. Mi opinión es que tener formación como coach profesional no es condición necesaria ni suficiente para ser Agile coach, pero por supuesto el aprendizaje de estas técnicas especificas enriquece muchísimo al Agile coach y aumenta el valor que puede aportar como tal.

Crear un camino de progresión y evolución de profesionales y equipos es una difícil tarea, para la que además de experiencia son necesarios un alto grado de empatía, inteligencia emocional y, sobre todo, capacidad de escuchar. Habilidades que, entre otras, se trabajan de forma especifica en el entrenamiento de un coach profesional. Sucede con estas capacidades, al igual que con muchas otras en el ser humano, que algunas personas cuentan con ellas de forma natural y otras no. Pero no podemos obviar que el entrenamiento especifico de la mayoría de las habilidades acelera y aumenta las posibilidades de su desarrollo.

 

Especialidad:

Según mi idea de organización ágil, esta es un sistema sostenible que es capaz de construir las cosas adecuadas con calidad y manteniendo un dialogo constante con su cliente mediante la entrega frecuente de valor.

 

Para lograr convertir una organización en un sistema de estas características es necesario aportar diferentes capacidades en distintos momentos dentro de la estrategia global de transformación. Y cambiar el todo paso a paso mediante la mejora continua de cada una sus partes (Continuously improve the whole)

Por esto, en diferentes momentos pueden ser necesario distintos especialistas, o tipos de coaches, que sean capaces de reforzar con herramientas especificas cada una de estas partes:

 

Coach Técnico: Experto en Construir las cosas adecuadamente (Build the things right).

El Coach técnico es experto en guiar a los equipos de desarrollo en la construcción de productos con alto nivel de calidad interna.

Para esto usa diferentes estrategias: desde hacer pair programming con personas del equipo de desarrollo para ayudarles a mejorar el código que escriben, hasta trabajar con IT OPs en la implantación de herramientas de integración y entrega continua, o diseñar e implementar con los equipos su estrategia de control de versiones.

 

Coach de Negocio: Experto en construir las cosas adecuadas & entrega y aprendizaje del cliente continuos (Building the right things & Continuously deliver and learn from your customer).

El coach de negocio se especializa en proporcionar herramientas para maximizar el retorno de la inversión en el producto construido y reducir el time to market.

Para esto el Coach de Negocio guía a dueños de producto y otros actores del negocio en el uso de herramientas especificas que mejoraran su capacidad de priorización, la gestión de necesidades funcionales y el alineamiento del producto construido con las necesidades de negocio que se pretenden cubrir.

 

El coach Organizacional: Experto en sostener el sistema y mejorarlo continuamente (Sustain the system + Continuously improve the whole).

El coach organizacional es un especialista en estructuras organizativas y sus procesos.

Es capaz de ayudar y guiar las organizaciones en la optimizaron de sus procesos y en su transformación a Agile. Para esto cuenta con instrumentos específicos basados en los principios Lean y Agile de transformación organizacional. Y la capacidad de instaurar una cultura de mejora continua en las organizaciones.

 

 

No quería cerrar el articulo sin dedicar un par de frases a las dotes de liderazgo con las que un Agile Coach debe contar para estimular y provocar el cambio. Así como el estilo de Coaching: ese indispensable toque de personalidad que un Coach imprime en su labor dejar en el en el su esencia, pasión y espíritu.

Conciliadores, fuertes, energéticos, duros, analíticos, resolutivos, parcos en palabras …. Cada Agile coach es un mundo, pero estoy convencido de que un buen Agile coach nunca deja indiferente.

 

Si quieres saber mas dobre este tema, puedes consultar …

http://www.agilecoachinginstitute.com/wp-content/uploads/2011/08/Agile-Coaching-Competencies-whitepaper-part-one.pdf

http://www.slideshare.net/agileindia/hiring-or-growing-right-agile-coach-by-lyssa-adkins-and-michael-spayd

http://yow.eventer.com/yow-2013-1080/hiring-or-growing-the-right-agile-coach-by-lyssa-adkins-and-michael-k-spayd-1367

https://www.youtube.com/watch?v=0OpeS_JKvtA

 

My ball is my goal

by

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Este es un juego para ayudar a organizaciones a entender el valor de tener objetivos compartidos, y demostrar que los grupos maximizan su rendimiento cuando marcan objetivos comunes por encima de la búsqueda de reconocimiento individual.Este juego debe realizarse en un espacio grande y cerrado. Dependiendo del material de las pelotas, puede ser muy ruidoso, se aconseja utilizar globos si necesitamos eliminar el ruido de las pelotas rodando por el espacio.
Material:
Pelotas: Para 10 participantes, 60-80 pelotas sería suficiente. Para más participantes puedes incrementar hasta aproximadamente 100.
Para 10 participantes puedes utilizar un espacio de unos 25-34 metros cuadrados.
Debes poder escribir en las pelotas y poder borrarlo. Puedes utilizar pegatinas pequeñas, por ejemplo.
pelota de ejemplo
Algún material para atar a algunas manos o piernas de jugadores, y un pañuelo para taparles la boca y que no puedan comunicarse, unos pañuelos de tela pueden ser suficiente.
Haremos rondas de 180 segundos ( 3 minutos ), en las que pondremos el timer en cuenta atrás. Colocaremos un timer grande a la vista de todos, y cada jugador tomará nota del tiempo que quedaba en el cronómetro cuando consiguió su pelota.
Ronda 1:
Cada jugador marca una pelota con un dibujo personal privado, que solo ellos saben. Debe ser una marca que solamente ellos entiendan. Se sueltan todas las pelotas en una habitación cerrada, tanto las marcadas por ellos como las que no. Cada jugador tiene un objetivo: tener su pelota en sus manos. Cuando el jugador encuentra su pelota debe anotar el tiempo que ha tardado, y se echa al suelo a esperar a que terminen los demás. Hay un premio individual, cada jugador obtiene beneficio según lo rápido que sea, simulando que el tiempo que quedaba es el premio que obtiene.
Ronda 2:
Los jugadores eliminan la marca privada de las pelotas, y las marcan con su nombre. El objetivo sigue siendo individual. Sólo cuando un jugador ha alcanzado su pelota, puede ayudar al resto de jugadores a encontrar la suya.
Ronda 3:
Igual que ronda 2, el objetivo sigue siendo individual. Ahora cualquier jugador puede ayudar al resto de jugadores a encontrar la suya desde cualquier momento.
Ronda 4:
Las pelotas siguen igual, con el nombre de cada jugador. Ahora el objetivo es diferente: Tenemos que buscar las pelotas de nuestros compañeros, aunque claramente está bien si encontramos la nuestra de camino. Seguimos midiendo cuanto tardamos en encontrar nuestra pelota, pero ahora la gente recibe sumando el tiempo de todos y dividiendo.

Jugadores con limitación especial:

– Existen jugadores con una mano atada a la espalda, otros con los pies atados ( o a la pata coja ) para no poder moverse tan rápido. Representan a personas que van más lentas que las demás.

– 2 Jugadores atados entre sí por las manos, y con un pañuelo en la boca para no poder comunicarse entre sí. Representan a personas que tienen un conflicto, y se entorpecen entre sí en la búsqueda de su objetivo.

 

Metáfora
Ronda 1: Organización donde cada miembro tiene un objetivo individual no compartido con los demás.
Ronda 2: Organización donde cada miembro tiene su objetivo propio, y sólo tras conseguirlo colabora con los objetivos de los demás.
Ronda 3: Organización donde cada miembro tiene objetivo propio, aunque si de camino puede , ayudará a los demás a conseguir el suyo.
Ronda 4: Organización con objetivo compartido, cada miembro recibe parte proporcional del resultado global que obtengan todos los miembros.

 

Resultados esperados:

Como es obvio, cada ronda mejorará los resultados individuales ( en media, habrá chicos con mala o buena suerte ) y sobre todo los colectivos . A excepción de personas que han tenido excepcional buena o mala suerte. En equipos que son por naturaleza colaborativo, se notará un salto muy significativo desde la ronda 2 a la 3, en lugar de notarse desde la ronda 3 a la 4 . En cualquier caso, es en la ronda 4 cuando comenzarán a preparar estrategias colectivas que aún así mejorarán resultados respecto a la 3.

 

Un ejemplo de resultados en un grupo real con 11 participantes es el siguiente:

resultados juego

 

Este grupo estaba formado por personas que eran miembros del mismo grupo, personas con carácter y actitud colaborativa. Por esto, se observa ya un gran salto en la 3a ronda. Los chicos intrínsecamente comenzaron a ayudarse aunque no fuera su objetivo. Sin embargo, Fue únicamente en la 4a ronda cuando decidieron buscar estrategias con un fin común, para obtener mejores resultados que beneficiaran a todos. Se observa que incluso las personas que iban con algún tipo de limitación ( cojos, mancos, parejas enfrentadas ) obtienen mejores resultados individuales en una organización que prima los resultados globales.

 

 
Improvement:
Muchas organizaciones hacen rankings internos de empleados, que posteriormente se utilizan para promociones. Se podría introducir un en las 3 primeras rondas que los 3 primeros en alcanzar su objetivo obtengan un premio ( entradas para el cine, masaje, invitación a cenar, tickets para algún otro evento… ) . El premio debe ser diferente en cada una de las rondas! Y en la última ronda, se puede ofrecer un premio común ( una cena para todos ) si alcanzan un total de puntos que sea bastante mayor que en la ronda anterior.

La ventana indiscreta (o cómo un poco de privacidad no viene nada mal)

by

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
A veces siento que las organizaciones han reaccionado frente a la locura de los cubículos del mismo modo que lo hacen los individuos cuando se dan cuenta que algo no funciona: haciendo justo lo contrario. Esta lógica, una especie de “mejora bipolar de procesos”, lleva a conductas o decisiones que no terminan siendo del todo racionales.
Mejor me pongo concreto, así no pierdo lectores. Me refiero a la “oficina abierta” o “espacio abierto” que tienen muchas organizaciones que intentan humanizar su entorno de trabajo. Claramente el extremo opuesto del cubículo, la falta completa de divisiones trae nuevos problemas. El principal en mi experiencia es la falta de privacidad. Ojo, privacidad no del individuo, sino del equipo. La unidad en la agilidad es el equipo, al que en parte pisoteamos si derribamos absolutamente todas las paredes.
¿En qué se siente la falta de privacidad? Falta de paredes desde donde irradiar información y sobre todo falta de paredes que aislen el ruido provocado por las conversaciones de sus integrantes. Los equipos que (sobre)viven en una oficina diáfana necesitan de la infame sala de reunión para tener la más mínima conversación animada. Esto incluye obviamente cualquier tipo de encuentro propio de varios métodos ágiles, como un standup meeting o una retrospectiva.
Y cuando digo pared, no tiene por qué ser opaca, claro. Actualmente estoy convenciendo a un cliente que en sus nuevas oficinas divida el espacio con paredes de acrílico. Gano espacio de irradiación, hablo tranquilo y sigo en contacto visual con mis compañeros de organización. Cuando esta división sea una realidad les cuento las nuevas alegrías y tristezas del caso.

Brainstorming the testing roadmap …

by

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

More questions anyone ?

 

There is a lot of talk about testing ; What is it ? How should it be done, by whom and when ?

But how do you put a testing process on the map ?  How do you think about ‘quality’ ?  What is it ?  How do we define it ?

How do we measure it (if we can measure it at all) ?  What’s already there ? What is missing ?

 

During my first days at King’s studio Phoenix, I watched the teams through the eyes of an agile  tester.  How could I, as a testing professional help, to not make, but also to maintain a kick-ass game ?”

And in order to set up a plan, I needed input …. preferably a lot of it and there are 2 great ways to get that ;  talk to the team on one side on dive right in and do some testing on the other one.   Start with a blank canvas, listen to people, note down questions they have, add questions and remarks you have, ideas, worries, problems, …

There are a lot of good ideas and healthy input swirling around but there also a distinct lack of how we can get those ideas into a mission and strategy in order to actually start executing them.  All of it valuable information to fill my canvas on 3 major topics :

Mission, strategy and planning

People say you need a good map to reach a difficult location.  But a good map is useless if you don’t have a location to go to.  Both need to be in place.  And there are a lot of things to consider :

  • Do we have a workable strategy / mission / test plan ?
  • How good is it ?
  • What is the update ratio of your test plan ?
  • Who tests what where and when ?
  • What do we measure and why ?

Of course, the more questions and things you note down, the more additional elements come up :

Testability

This is both a goal and a means to an end.  You cannot follow your strategy if you don’t make sure you can actually test your games, but your strategy should also define what testability is.

It also includes information on what we want from a build, from a release and what we are sending to other teams and people.

  • How do we make sure a build in testable within the team and within the sprint ?
  • What sign-off criteria should we use before sending out a build to other testing parties ?
  • Do we have the right environment set up ?
  • What is ‘perceived quality’ ?
  • Do we have all the tools and are we using them to the best of their and our abilities ?

Measuring and reporting

And finally there is the big question “When is it good enough ?”  When can you stop testing ?  Ask any tester and he or she will say ‘never’.  We don’t run out of test cases or ideas, don’t guard the gates to a release, … For us there is always more to do but where do we draw the line between ‘more to do’ and ‘deliver optimal value’ ?

  • How do you report these things ?
  • What do other team members and stakeholders want to see reported ?
  • What / When is “Done” ?

You have to start somewhere in this mountain of feedback so next up will be to identify some of the first order measurements ; Things we can do quick and easy, with a low cost and a high gain / visibility to team and test improvement.  So up next will be how we define these steps and make the proper tasks out of them.

 

 

 

 

Adapting the Inception Deck

by

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Many of you are probably familiar with the Inception Deck. It is a tool to get all the stakeholders aligned at the beginning of a project or product development. The idea is to get this alignment to happen with the least paperwork possible. The Inception Deck provides a set of 10 exercises to be done in order to achieve this in a lightweight fashion. The original Inception Deck can be found in the book Agile Samurai.

To refresh your memory, here you have a short summary of the Inception Deck parts:

  • Why are we here? – Makes  purpose of the project clear
  • Elevator Pitch – Describes in one sentence what the product does and why it’s different
  • Product Box – Provides a visual description of the product properties
  • NOT List – Puts a limit to the scope
  • Meet your neighbors – Lists all the stakeholders
  • Show the solution – Provides a high-level architecture of the solution
  • Up at night – Describes the major risks
  • Size it up – Gives a high level estimate of the time to conclude it
  • What’s going to give? – Defines the priorities for making decisions
  •  What’s it going to take? – Estimate how much money it will cost

At Criteo we have started some major change initiatives and during the project inception phase we wanted to make sure we were aligned. The Inception Deck seemed like a perfect candidate. But the question is: which parts are valid for change management? It’s pretty obvious that “show the solution” is not a great fit. First of all, there is no architectural solution in change management. There are at most potential alternatives for experiments to run. Furthermore, the NOT List is too vague for our purposes, as it’s not easy to make a list of features. Most of these things will be discovered as we go.

What we noticed was missing was a proper way to describe the current environment, the vision where we wanted to go, and some strategies on how to get there. For this purpose the Graphic Game Plan chart is a perfect fit. We got this chart from the Visual Meetings book, which we highly recommend. You can see an image of the chart we added below. In a way, this chart could be considered to “Show the Solution”. Not in a technical way, but in a strategic way.

vision

Furthermore, there was no high level plan which in the Inception Deck is targeted by the NOT List. What we did for this purpose was to bastardize the User Story Mapping. Instead of putting the different steps of a product for the Skeleton, we discussed which high-level initiatives we were going to drive. For each of these initiatives, instead of adding product features, we discussed organizational habits to change. The following image shows how we presented it.

storymapping

Finally, in change management there is a lot of risk and we wanted to be able to counter it. For this purpose, on top of the “Up at Night” exercise we also did a SWOT analysis to make sure we didn’t forget anything.

swot

We learned a lot from using a modified version of the Inception Deck for starting a change management initiative. The most interesting was that no one had actually done an Inception Deck before except the coach, therefore even this was a change. Taking into account the culture of the company you are attempting to change is very important, and this was not taken into account. This is very important when communicating with the rest of the company. Next time we try to use the Inception Deck we will probably do an exercise to describe your communication strategy which can tie nicely with Schneider’s cultural model. This was one of the biggest things we found lacking. For this purpose we would use an exercise like the one in the image below.

influence

As a summary, we propose the following exercises for the Adapted Inception Deck:

  • Why are we here?
  • Elevator Pitch
  • Product Box
  • Show the solution (Graphic Game Plan)
  • Habit Story Mapping
  • Meet your neighbors
  • Up at night + SWOT analysis
  • Communication canvas
  • Size it up
  • What’s going to give?
  • What’s it going to take?

Back to life

by

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Dear reader,

After some problems with our hosting provider, we are finally back to our place. We thank you for your patience, we will be restoring all our old posts, and will continue writing new posts about everything around software development, management, technologies, agile organizations, events… everything we are interested at!