viernes, 28 de julio de 2017

¿Cómo son las historias de usuario de marketing?

Ejemplos de historias de usuario de marketing
Gracias Jim y Fernando
Fernando, un alumno de los cursos on-line Scrum Manager de mayo de 2017, inició un tema interesante; no siendo técnico y viniendo de marketing preguntaba sobre cómo debería de escribirse una historia de usuario para el caso de un fármaco, un cliente que buscara el desarrollo de una vacuna inexistente para una nueva enfermedad xx en pacientes de rango etario yy a zz de edad.

Profundizando en el tema me topé con el blog sobre Marketing Agile de Jim Ewel que describe de un forma excepcional como son las historias de usuario de marketing.

Como ejemplo de historia de usuario de marketing Jim propone entre otras la siguiente:

"Como madre quiero grabar y compartir vídeos de los niños para poder compartir momentos importantes con los abuelos, tíos y amigos"

Si nos fijamos está escrita con el patrón que recomienda Mike Cohn:

Como [rol del usuario], quiero [objetivo], para poder [beneficio]

con matices algo diferentes:

Como [cliente ideal], quiero [nuestra solución], para [que sus problemas desaparezcan]

En marketing también se utilizan User-Personas para describir de forma ficticia al público objetivo, para poder diseñar sitios web, escribir material de marketing y generar contenido (publicaciones de blog, videos, libros electrónicos, etc.) que satisfagan sus necesidades. La solución nos hace centrar en lo que los clientes quieren lograr, ya sea resolver un problema, aliviar un dolor o aspirar a algo mejor a través de nuestro producto. El "para" trata la pregunta que un buen marketing debe responder: ¿Qué hay en él para mí? (What’s In It For Me? - WIIFM).

Jim Evel nos compara los dos tipos de historias de usuario en la segunda parte del post sobre historias de usuario de marketing:

Historias de usuario de TI
Historias de usuario de marketing
Bajo nivel
Alto nivel
Número elevado de estas en la pila
Relativamente pocas en la pila
Hemisferio izquierdo del cerebro
Hemisferio derecho del cerebro
Focalizadas en funcionalidades
Focalizadas en resultados

Las historias de usuario de TI son detalladas y tienen una granularidad muy fina, las de marketing son cosas amplias, por tanto la pila de producto de marketing suele ser corta. Lo interesante es en lo que se focalizan, las historias de TI al hablar de funcionalidades están orientadas a la parte racional de las personas, las de marketing a la parte emocional (fijémonos en el ejemplo más arriba de la madre que quiere grabar a sus niños, sus razones son emocionales). Cuando la gente habla de marketing, por ejemplo de anuncios que les han impresionado, hablan de cómo les han hecho sentir, acerca de como cambió su día o cómo les hizo reír histéricamente.

Veamos pues como sería la historia de usuario sobre el fármaco de Fernando:

"Como farmacéutico quiero el desarrollo de una vacuna para prevenir la malaria en pacientes de rango etario de 4 a 13 años de edad para mejorar la calidad de vida de la población afectada"

Historia de usuario terminada - cortesía de Pixabay
Recordemos que las historias de usuario, que van a la pila de producto son "qués", aquello que necesitamos o queremos para resolver un problema, y el desarrollo de la vacuna inexistente sin duda es un "qué". En la pila de sprint se desglosará esta en los "cómos", las tareas o desarrollos a resolver, que en este caso podrían ser: descomponer del target del mercado, patología, composición de la droga preliminar, forma de aplicación de dosis, etc.

Tal como prescribe Scrum debe de haber una definición de hecho (DoD) para considerar la historia como terminada, por ejemplo, "y la vacuna pasará los controles de calidad e irá embotellada y etiquetada". Finalmente se añadirán los criterios de aceptación que van servir para comprobar si la historia cumple con los requisitos, por ejemplo: "realizar la comprobación que la vacuna funciona al xx% en una muestra de zz personas".

Mis agradecimientos a Fernando por haberme impulsado a escribir este post.

sábado, 22 de julio de 2017

¿Cómo preparar a los futuros profesionales para la colaboración y la autoorganización?

Alumna eduScrum Master actualizando el burndown
Una de las áreas donde se está explorando la aplicación de Scrum es la educación. Desde 2011 en Holanda diversas escuelas practican en clase un marco derivado de Scrum, una iniciativa del profesor de química Willy Wijnands, que bautizó con el nombre de eduScrum.

En eduScrum el aprendizaje toma el centro del escenario: aprender de forma más inteligente, mejorar la colaboración y llegar a conocerse mejor a uno mismo, sobre pilares de transparencia, inspección y adaptación y con equipos autoorganizados. Esta forma de trabajar crea una mayor responsabilidad, diversión y energía, construye sobre las motivaciones de autonomía, maestría y el propósito, lo que conduce a mejores resultados y a tiempos de aprendizaje más cortos. Los estudiantes experimentan un fuerte crecimiento personal que refuerza la confianza en sí mismos y en los demás. Con eduScrum prepararmos a nuestros chicos de secundaria para convertirse en los profesionales del siglo XXI, donde lo que importa es la colaboración y no la competitividad, 

"eduScrum es un marco para el coaching de estudiantes donde la responsabilidad del proceso de aprendizaje se delega de los profesores a los estudiantes"

El equipo eduScrum está formado por el equipo de estudiantes (4 estudiantes) + el eduScrum Master (estudiante, uno de los 4) + Propietario del Producto (profesor).

El Propietario del Producto es el responsable de la pila de productolista priorizada de objetivos de aprendizaje o capítulos del tema a estudiar en forma de historia. A diferencia de Scrum también vela por el proceso, y lo va delegando al eduScrum Master a medida que este coge experiencia.

El eduScrum Master es el responsable de velar por el tablero u "hoja", actualizar el burndown y de asegurarse que su equipo de estudiantes sigan las reglas.

Los alumnos estudian de forma colaborativa en equipo, parten de las historias que el Propietario del Producto ha priorizado en la pila de producto, y al ser propietarios de su propio proceso de aprendizaje crean, estiman con planning poker y se autoasignan las tareas que consideran necesarias. Por ejemplo, son ellos mismos los que definen sus deberes. Si tienen dudas requieren del Propietario del Producto para tratarlas adecuadamente. 

Los sprints son de uno a dos meses, en la planificación sprint se forma cada vez un equipo de estudiantes nuevo y se determinan los objetivos aprendizaje. La reunión de a pie se hace antes de clase y en ella los estudiantes dan respuesta a las tres preguntas referidas a los objetivos de aprendizaje. Cuando todas las historias estás hechas según DoD el Propietario del Producto hace un examen, si el equipo no lo pasa, las historias vuelven a la pila de producto.

A modo de mejora continua después de la revisión de sprint se realizan una retrospectiva a nivel del equipo y una reflexión personal a nivel de cada estudiante.
"Hoja" o tablero eduSrum
El tablero u "hoja" de eduScrum tiene dos columnas para el Propietario del Producto, "Historias" donde pone los capítulos del tema y los "Criterios de Aceptación" del temario que los alumnos han de trabajar. Los alumnos crean las tareas que colocan en "Pendiente" y hacen avanzar a través de "Ocupado" a "Hecho".

En el tablero se muestran los criterios de hecho (DoD) y los criterios de divertido (DoF) que son acuerdos entre alumnos y profesor. En otras áreas a tal efecto se muestran el burndownlos impedimentos que van afectando el sprint.
 Para quienes quieran profundizar en esta forma de aprendizaje colaborativo les dejo un link para descargar la Guía de eduScrum, "Las reglas del juego" creada por el equipo de eduScrum.

Maria Montessori en la renovación de los métodos pedagógicos de principios del siglo XX

sábado, 15 de julio de 2017

¿Cómo gestionar las acciones resultantes de las retrospectivas?

Scrum Master facilitando una
retrospectiva, gracias Marisa :-)
Una de las responsabilidades del Scrum Master es la de asegurarse que el equipo cierre las retrospectivas con acciones, una por retrospectiva, que sean posibles hacer durante el siguiente sprint. Recordemos que a través de las retrospectivas estamos estableciendo una cultura de mejora continua en la que equipo mejora su forma de trabajar con cada sprint.

Para asegurarnos que el equipo obtenga beneficio de las acciones propuestas, estas deben de gestionarse. Sin esta gestión las acciones de mejora pueden perderse o retrasarse innecesariamente, y el equipo puede perder la confianza en el marco de mejora continua. Suele ser frustrante si retrospectiva tras retrospectiva no hay acciones de mejora que se hayan materializado, en estos casos los equipos hasta dejan de hacer la reunión.

Las acciones resultantes de una retrospectiva deben de ser claras y entendidas por todos los involucrados, equipo de desarrollo y Propietario del Producto, y todos deben de estar de acuerdo en que las acciones son válidas.

Es recomendable que sean pequeñas y potentes, estén escritas con un patrón que incluya el porqué, la razón de esa acción o los problemas que resolverá, así como los beneficios que aportará, y también la persona o las personas que se la llevarán para gestionarla o hacer una exploración para determinar si se produce una mejora para el equipo en el siguiente sprint.

En función de la naturaleza y el tamaño de las acciones podemos llevarlas a diferentes pilas:

Acciones pequeñas al siguiente sprint, pueden incluirse en post-its de otro color el la pila de sprint en el scrum board. Ejemplos de ello pueden ser acciones como:
Acciones grandes a la pila de producto, suelen ser acciones que requieren de un esfuerzo estimable y que por tanto deben de tenerse en cuenta en la planificación de sprint y pueden, o no, entrar en el siguiente sprint. Ejemplos clásicos son:
  • Carencia en la formación técnica o de negocio
  • Preparar un máquina para integración continua
  • Refactorización mayor
Para acciones de mejora que sean acuerdos del equipo llevarlas al tablero de políticas explicitas, usualmente un área específica del scrum board:
Impedimentos que surjan en las retrospectivas se los lleva el Scrum Master, recomiendo tener un tablero específico para éstos:
  • Aligerar documentación de seguimiento (clásico de la PMO)
  • Rendimiento de las VDIs (máquinas virtuales), incrementar su RAM
  • Entorno de test estable y réplica de producción

viernes, 14 de julio de 2017

¿Hay nombres para la disfunciones de los roles de Scrum?

Good Scrum Master
Cortesía de Pixabay
A lo largo de mi experiencia en diferentes compañías, charlas con compañeros coaches y trainers y recorriendo algunos blogs la web, he recopilado unos pocos términos disfuncionales para el Scrum Master y el Propietario del Producto que me han hecho mucha gracia. En especial el post "The Scrum Master as the Change Leader" de Barry Overeem menciona algunas disfunciones de Scrum Master que me han hecho reír mucho. :-D

Good Scrum Master: el Buen Scrum Master que solo se dedica a ser Scrum Master. Se dedica de forma efectiva a ser el facilitador de todo el proceso, cuida que se cumplan las reglas de Scrum, se responsabiliza de que haya mejora continua, facilita las reuniones, forma y acompaña al equipo de desarrollo y al Propietario del Producto en el aprendizaje del marco, gestiona la resolución de impedimentos, motiva la colaboración desde los valores ágiles y participa e impulsa el cambio cultural de forma gradual en la organización.

Ugly Scrum Master: Un Scrum Master Feo es el que es a la vez miembro del equipo de desarrollo y Scrum Master. Usualmente se habla de disfunción porque el foco de ambos roles es otro, tecnología y coaching son cosas muy distintas, es difícil entrenar bien a un Scrum Master y no debemos menosvalorar la importancia del rol ni los desafíos a los que se enfrenta. La persona que hiciera ambos roles puede entrar en conflicto cuando producto/proyecto y proceso choquen, debiéndose inclinar por uno o por otro. Un desarrollador va a dar prioridad al producto ya que en primera instancia es constructor de producto.

Bad Scrum Master: Un Mal Scrum Master es a la vez Propietario del Producto y Scrum Master; un Scroduct Ownster como lo bautiza Atlassian en su serie de "The wrong way to do Agile". La Scrum Guide prohíbe explicitamente esta combinación, el Propietario del Producto busca el mejor producto posible, el Scrum Master el mejor equipo posible y si combinamos ambos puede convertir a la persona en un jefe de proyecto despótico.

Executive Scrum Master: Un Scrum Master Ejecutivo es un ex jefe de proyecto que aprendió a planificar en cascada y a ejecutar los planes por fases, entiende Scrum pero intenta llenar las supuestas carencias que detecta desde su perspectiva con sus técnicas de planificación. Tiene el foco fuertemente anclado en el cumplimiento de del sprint, en ver como el proceso toma forma y se asienta, y no es consciente de la parte esencial referente a los aspectos humanos, en desarrollar a los miembros del equipo y proporcionarles un entorno en el que aprendan de forma continua.

Scrum Police Officer: El Oficial de Policía Scrum es un Scrum Master que probablemente forme parte de una oficina de proyectos y que sigue rigurosamente las reglas de Scrum o las reglas de la metodología adaptada por la organización. Lo hace con cero empatia por la situación y contexto del equipo, simplemente si este no actúa de acuerdo con las reglas está mal hecho, independientemente de si aplican o aportan al equipo. Las acciones de mejora de las retrospectivas que no "encajan" simplemente son ignoradas con la afirmación que no admite duda: "somos así y eso no va a cambiar, ¡somos profesionales!"

Scrum Mother or Father: Scrum Master maternalista o paternalista que cuida de su equipo como si fuera una madre o un padre. Aplica las normas de autoridad o protección tradicionalmente asignadas a la madre o al padre de familia al ámbito laboral, en este caso al equipo de desarrollo. La consecuencia conlleva una reducción de la libertad y autonomía del equipo, siempre dependerán de este tipo de Scrum Master. A veces un Scrum Master ha de apartarse para que los equipos cometan sus propios errores y aprendan de ello.

Scribe Scrum Master: El Scrum Master Escribano que toma notas de todos las reuniones de Scrum, documenta exhaustivamente las planificaciones de sprint, las reuniones diarias, los refinamientos, las revisiones de sprint y las retrospectivas. Probablemente sus superiores miden su "eficacia" por el número de palabras de sus informes.

Team Boss Scrum Master: El Scrum Master/Jefe de Equipo, o como se suele llamar a si mismo "líder al servicio". Es el jefe, quien ficha y despide, el que decide quien merece un aumento de sueldo y quien no, el que premia y penaliza, el que se encarga de mantener las buenas costumbres en el equipo como por ejemplo hacer dos horas extra al día como buenos porfesionales, el que decide quién está más capacitado para cada una de las tareas del sprint...

Secretary Scrum Master: El Scrum Master Secretario que planifica todas las reuniones de Scrum y las agendas en los calendarios de todos los miembros del equipo, Propietario del Producto e interesados... y otros jefecillos, gerentes y hierbas varias. También es responsable de mantener los calendarios de los equipos actualizados con días festivos y vacaciones.

Chairman Scrum Master: El Scrum Master Presidente de la reunión diaria, al que todas las mañanas el equipo proporciona una actualización de la situación actual. Así el Scrum Master obtiene la información necesaria para escribir el informe de situación diaria a sus superiores, informe estratégico para el buenhacer de la compañía. :-P

The Admin Scrum Master: El Scrum Master Administrador, si el equipo necesita un cambio en JIRA, Redmine, CCM, iceScrum o cualquier otra herramienta el Scrum Master es tu amigo, él conoce todos los flujos de trabajo de memoria y haciendo honor a su rol es el experto en herramientas.

Good Product Owner
Cortesía de Pixabay
Good Product Owner: un Buen Propietario del Producto es aquél que se integra en el equipo, está disponible, lo apoya y asiste a todas las reuniones. Tiene una visión de lo que desea construir y es capaz de transmitir la visión al equipo de desarrollo, al inicio a través de la visión del producto, y a lo largo de los sprints a través de la pila de productoUn buen Propietario del Producto motiva al equipo con una meta clara y elevada.

Phoenix Product Owner: un Propietario del Producto Fénix es aquél que desaparece al finalizar la planificación de sprint y no reaparece hasta dos semanas después en el inicio de la revisión de sprint. Puede tener una pila de producto bien preparada, con elementos bien trabajados y lo puede estar haciendo de sprint en sprint, su carencia reside en que no está disponible para el equipo durante el sprint y por tanto no resuelve dudas ni da feedback en caliente, minimizando de esta manera las posibilidades del marco de Scrum.

Proxy Product Owner: El Propietario de Producto Proxy es un corre-ve-y-dile que no tiene conocimiento profundo del negocio ni poder de decisión. Algunas compañías distribuyen el rol en dos, un gerente del producto, o product manager, y un "Propietario del Producto" Proxy. El gerente del producto se encarga de los aspectos de comercialización y gestión del producto, posee la visión, se relaciona hacia negocio y por tanto se mantiene en contacto con el mercado. El proxy tiene las funciones de secretario para la pila de producto y la de interfasar con el equipo de desarrollo, por tanto se difumina la responsabilidad, se producen retrasos y otros desperdicios como cuellos de botella en la toma de decisiones y una disminución de la productividad y la moral.

Mis agradecimientos a Alexandre y a Marcos que han aportado algunas disfunciones resultantes de sus experiencias :-)

jueves, 13 de julio de 2017

¿SAFe es un marco empírico en evolución continua?

Realmente lo que me hacía gracia para escribir este post era poner en orden las diferentes versiones del "Big Picture" de SAFe que he ido encontrando a lo largo de la web.

SAFe es un marco que está en continua evolución, parte de una amplia base de conocimiento como son Lean Thinking, Lean Product Development, Ingeniería de Sistemas, Agilidad, System Thinking y otros, y se va actualizando y refinando constantemente con aquello que su equipo aprende con cada implementación. Cuando me formé con Dean Leffingwell este nos contaba lo agradecido que estaba a cada compañía por el feedback y el aprendizaje que suponía cada una de las implementaciones.

En sus inicios SAFe publicaba actualizaciones frecuentes, actualmente lo hace de forma anual, veamos la evolución de sus "Big Pictures" :-)

..., 2008, 2009 - The Agile Enterprise

En años previos a Scaled Agile Dean Leffingwell describe en su post "Enterprise Agility–The Big Picture" como trabajando con los ejecutivos de Symbian Software Ltd. trataba de darles un "Big Picture" de como quedaría la compañía después de adoptar Agile a nivel de la empresa. 
Big Picture - The Agile Enterprise - 2008Big Picture - The Agile Enterprise - 2009

2011 - Scaled Agile Framework 0.X

En la fase de construcción del marco Dean Leffinwell y su equipo completan los textos a nivel de equipo, crean el logotipo y añaden nuevos iconos como el RTE "Release Train Engineer" y de recursos compartidos "Shared". Podemos ver el avance en su post "Scaled Agile Framework Big Picture Update".
Big Picture versión 0.8 - Scaled Agile Framework - 2011Big Picture versión 0.93 - Scaled Agile Framework - 2011

2011 - Scaled Agile Framework 1.0

En 2011 SAFe presenta la primera versión oficial del interfaz de usuario principal, el "Big Picture", que pone de relieve los roles individuales, equipos, actividades y artefactos necesarios para escalar Agile a nivel de empresa, desde el equipo individual al equipo de equipos.
Big Picture versión 1.0 - Scaled Agile Framework - 2012

2011 - Scaled Agile Framework 2.0

El mismo año de la primera versión SAFe lanza la versión 2.0, una versión mayor en la que refina sensiblemente el nivel de Portfolio.
Big Picture versión 2.0 - Scaled Agile Framework - 2012

2013, agosto - Scaled Agile Framework 2.5

Con esta versión SAFe añade nuevos contenidos sustantivos en todos los niveles: Team, Program y Portfolio. Explicita en el "Big Picture" como los objetivos los identifican los equipos y se agregan a nivel de ART. Estas adiciones están destinadas a acelerar aún más los beneficios empresariales que la aplicación del marco ha estado brindando a los usuarios de todo el mundo.
Big Picture versión 2.5 - Scaled Agile Framework - 2013

2014, agosto - Scaled Agile Framework 3.0

La versión 3.0 no trae cambios estructurales en el marco, el enfoque principal es resultar más fácil de entender y mejorar la representación de cómo funcionan los 3 niveles (Team, Program y Portfolio) y cómo se podrían aplicar a una organización grande, especialmente en el nivel de Portfolio.
Big Picture versión 3.0 - Scaled Agile Framework - 2015 

2016, enero - SAFe 4.0 for Lean Software and Systems Engineering

La versión 4.0 incorpora nuevos constructores con un nuevo nivel, llamado "Value Stream", que está diseñado para aquellas compañías que construyen los sistemas más grandes y complejos del mundo. Incluye guía para líderes Lean-Agile, orientación para la formulación de estrategias y la comunicación del portfolio. Los ARTs alinean a los equipos a una misión común apoyados por arquitectura y UX, e introduce Kanban y flujo a nivel de equipos.
Big Picture expandido versión 4.0 - SAFe 4.0 for Lean Software and Systems Engineering - 2016

2017, junio - SAFe for Lean Enterprises 4.5

Con la versión 4.5 SAFe proporciona una introducción más sencilla al marco a través de sus configuraciones "Full SAFe", "Large Solution SAFe", "Portfolio SAFe" y "Essential SAFe". Introduce temas como "Lean UX", "Continuous Delivery Pipeline" y "Scalable DevOps", la novedad más grande de esta versión. También incluye el "Implementation Roadmap", una descripción más detallada de como introducir SAFe en una compañía.
Big Picture completo versión 4.5 - SAFe for Lean Enterprises - 2017

lunes, 10 de julio de 2017

¿Para los equipos ágiles son mejores los especialistas o los generalistas?

Los métodos ágiles están concebidos para dar la máxima importancia a las personas y potenciar sus capacidades. Estas personas son las que forman los equipos que construyen los productos software. Uno de los asuntos importantes de los que ocuparse respecto a la constitución de los equipos, es que no haya equipos que dependan de uno sólo de sus miembros para ningún asunto, es decir si esta persona no está (por ejemplo, le toca la lotería y deja el trabajo) el equipo puede seguir adelante con el producto software que están construyendo. De esto se deduce que es importante disponer de generalistas, pero como vamos a ver en el desarrollo software también es necesario disponer de especialistas.

Si acudimos a la historia, antes de la revolución industrial todo lo construían artesanos. Una característica de los artesanos es que el producto completo lo construye una única persona. Esta realiza todas las tareas necesarias para construir el producto, no está especializado y es en este sentido, un generalista. A finales del siglo XVIII, se vislumbró la importancia de la especialización de las personas y se demostró que varias personas especializadas siguiendo un proceso previamente definido, podían obtener mejores resultados que cada una por separado. Para que se entienda mejor, recurramos al ejemplo de la fábrica de alfileres del economista y filósofo Adam Smith (1723-1790). Smith dividió el proceso de construcción de un alfiler en tareas, simplificando: tensar el alambre, cortarlo, afilarlo, construir la cabeza, pegar la cabeza al alambre y colocar el alfiler en un papel. Lo que Smith demostró es que si tenemos 10 operarios y cada uno tenía que hacer todas las tareas, podría construir hasta 20 alfileres al día. Sin embargo, si se especializaba a los operarios por tarea entre todos serían capaces de construir hasta 48.000 alfileres al día. La especialización mejora la productividad en este caso.


Si miramos la especialización desde el punto de vista del conocimiento, trae como consecuencia un aumento de la capacidad de profundizar. Los avances científicos de los últimos 200 años han sido numerosos y en gran parte se han hecho posibles gracias a la especialización. Los frutos de la especialización han mejorado la vida de la humanidad: mejores fármacos, cirugía no invasiva, maquinaria avanzada, nuevos materiales, ordenadores, robots, etc.


Hemos visto que en los equipos de desarrollo software es deseable disponer de generalistas, pero también los especialistas son de vital importancia. Los generalistas nos ayudan a que el producto no dependa de determinados integrantes del equipo, sino del equipo completo. Los especialistas nos ayudan a utilizar la tecnología de la forma adecuada, siendo capaces de sacarle el máximo partido a los lenguajes, los frameworks, los IDEs, los repositorios de código, los servidores de integración continua y mucho más. En el mundo del software que cambia día a día y en el que hay tantas tecnologías emergentes, son muy importantes los conocimientos detallados. Es imposible que un desarrollador aglutine todo el conocimiento, una sola persona no puede abarcar todos los conocimientos tecnológicos necesarios para construir y explotar los productos que necesita una organización. Entonces, por una parte necesitamos especialistas que conozcan todos los detalles de determinadas tecnologías y por otra parte necesitamos generalistas que sean capaces de abordar asuntos de más de una especialidad.


Ser generalista y especialista al mismo tiempo ¿Es posible? Pues sí. Un desarrollador profesional se puede especializar en algunas tecnologías y por otra parte interesarse por tecnologías que están utilizando otros miembros del equipo. Interesarse en el sentido de ser capaces de comprender el código que el especialista ha construido/instalado/configurado y hacerse cargo de dicho trabajo.


La idea que subyace es la que describió David Guest en 1991 y más tarde popularizo Tim Brown y es el concepto de perfil T-shaped. Este perfil describe los atributos que son deseables en un trabajador. La barra vertical de la T se refiere a conocimientos detallados que profundizan en áreas específicas, mientras que la barra horizontal se refiere a la habilidad de colaborar con expertos en otras áreas de conocimiento y la disposición para utilizar el conocimiento adquirido en esa colaboración.

Concepto T-shaped
En conclusión es deseable y necesario que cuando se organice un equipo, por una parte los integrantes sean capaces de reunir conocimientos detallados de aquellas tecnologías que se vayan a utilizar y que por otra parte estén dispuestos a aprender de la especialización de los otros integrantes del equipo y enseñarles sobre su propia especialización. También hay que tener en cuenta que la especialización de los profesionales no surge de la nada, es decir es sano que el trabajo de un equipo consista en una mezcla de desarrollo e investigación. En el desarrollo software, la tecnología cambia día a día y para que los desarrolladores estén a la última es necesario que alguna parte de su tiempo lo dediquen a investigar y aprender. Este tiempo les aseguro, no será un tiempo perdido.

viernes, 7 de julio de 2017

¿La escucha activa ha de ser una habilidad blanda de buenos Scrum Masters y Agile Coaches?

Escucha activa y humilde - cortesía de Pixabay
Mi compañero Carlos me mostró un librillo de "Ética empresarial para minorías creadoras" de la Universidad Francisco de Vitoria que dedica dos páginas a la escucha humilde, páginas que me cautivaron al instante.

Los equipos autoorganizados no se basan en grandes especialistas, sino en personas abiertas a aprender y que deben de entender la importancia de reconocer las contribuciones de los demás. Desde la perspectiva de un equipo ágil la humildad es un valor compartido para poder reconocer la diversidad de las experiencias, las opiniones y las ideas del resto de miembros y de ser capaces de recibir feedback de usuarios, clientes e interesados en general. 

Scrum Masters y coaches ágiles necesitan dominar habilidades blandas o soft skills que les ayuden a desarrollar a las personas y a facilitar reuniones y talleres. Entre estas habilidades, que ha de tener el propio coach y también desarrollar en los miembros de los equipos de Scrum, están entre otras la escucha activa, la asertividad y las de dar y recibir feedback. Establecer una escucha activa humilde nos permite conocer verdaderamente la visión del cliente, entender y cuestionarse los problemas que hay detrás de los requisitos desde diversas perspectivas y por tanto participar en la construcción de las mejores soluciones, las que más beneficios aporten o más problemas de negocio resuelvan.

He transcrito las sugerencias que vienen en ambas páginas del librillo, son una auténtica lección de vida:
  • Solo podrás sacar lo mejor de cada uno escuchando.
  • Solo puedes escuchar si a la vez no intentas hablar tú: solo puede haber una dirección.
  • El librillo de la Universidad Francisco de Vitoria
  • Escucha como encuentro y recepción de alteridad: quién no escucha, no acepta a los demás.
  • Escucha activamente: otorga valor a las ideas de los demás, pon interés.
  • En todo lo que alguien nos dice hay información explícita e implícita: lo que dice de algo y lo que dice de si mismo.
  • En el mensaje sé capaz de leer al mensajero: quiere regalarte algo.
  • Sin el mensajero, no hay mensaje.
  • Escucha con paciencia y humildad: escucha hasta la última gota.
  • Escucha con humildad valorando a tu interlocutor: tiene que notar que no solo te importa el mensaje, sino él, como portador del mensaje.
  • Asiente, muestra interés y entusiasmo, mírale a los ojos y sitúate cerca de él.
  • Repite sus palabras cuando te parezcan muy importantes y resalta las partes medulares de su exposición preguntándole si has entendido bien lo que quiere decir.
  • No le interrumpas, después de cada frase o idea pueden venir más: lo mejor está siempre al final.
  • Anota las ideas importantes con sus mismas palabras.
  • Concéntrate en su exposición: a veces lo importante está escondido en su exposición.
  • Y recuerda: lo importante no es lo que tú quieres escuchar o lo que tú opines, sino lo que él quiere expresar.

jueves, 6 de julio de 2017

¿Cómo entrenar a los Scrum Masters para facilitar la reunión diaria?

Scrum Master estresado - cortesía de Pixabay
Una de las primeras disfunciones clásicas de lo equipos que se inician en Scrum son la duración y el contenido de la reunión diaria. Sin la correcta facilitación de un Scrum Master se pueden convertir en reuniones que duran hasta horas enteras y en las que se tratan todo tipo de temas ajenos a la diaria

El caso más disfuncional que he presenciado fue en mi incorporación como Scrum Master a un equipo que llevaba haciendo "Scrum" durante más de 2 meses a su "manera". 

Tenían una grave carencia del conocimiento técnico del framework del cliente, así que habían incorporado a Vanessa, una técnico de sistemas experta en el framework, cuya presencia era para resolver dudas técnicas. No podía dar crédito a lo que vi en la primera reunión diaria, cada miembro del equipo se dedicó a reportar el trabajo hecho a esa chica, y ella contrariada e impaciente ¡¡¡movia el pie derecho con nerviosismo!!! La mayor parte de la reunión transcurrió con la resolución de dudas sobre el framework... dudas que no afectaban a todos los miembros.

En general una diaria disfuncional es indicador de inmadurez, por lo que entrenar bien a los nuevos Scrum Master para facilitar de forma eficiente la reunión diaria, toma mucha relevancia. Para ello podemos emplear el ejercicio descrito por Bill Wake "Daily Scrum from Hell".

Para el ejercicio, que suele durar aproximadamente 15 minutos, necesitamos un Scrum Master, de 6 a 8 miembros de equipo, de pie preferiblemente en semicírculo ante un scrumboard, y algún observador invitado.
Para el ejercicio habremos preparado una serie de fichas con instrucciones secretas. 10 de ellas con el mensaje "Responde a las tres cuestiones" y otras 10 con mensajes boicoteantes como:
Ejemplo de fichas, thanks Sabine
  • Dirígete exclusivamente al Scrum Master (ignorando a todos los demás a menos que se te haga una pregunta directa).
  • Llegar tarde.
  • Menciona un impedimento sin ser claro cuál es.
  • Comienza diciendo, "Solamente soy un observador" para luego explicar algo que esté absolutamente fuera del contexto.
  • Como observador y como si tuvieras turno en la reunión di "paso" o "solo estoy observando".
  • Haz una pregunta para clarificar el turno de otro miembro.
  • Divaga en las 3 respuestas hasta que te insten a pasar turno.
  • Trata de desviar la reunión.
  • Trata de resolver el problema de alguien.
  • Comienza una discusión lateral.
Se empieza explicando el trasfondo de la reunión diaria:
  • Las tres preguntas que cada miembro responde y el flujo de la reunión:
    • Lo que has hecho desde la reunión diaria anterior
    • Lo que harás hasta la reunión siguiente (autoasignación de tareas)
    • Los problemas que tienes o si prevés tener algún impedimento
  • Describir disfunciones que puedan ocurrir, como por ejemplo:
    • Discusión lateral: pídeles que escuchen cuando están hablando.
    • Miembro divagando: pídele que resuma más rápidamente.
    • Reunión desviada: pide a la gente que tenga una reunión inmediatamente después de la diaria para tratar el tema exclusivamente con los interesados.
    • Observador que habla: recuérdale que se limite a ser un observador.
Se explica al grupo el contexto del ejercicio:
  • Imaginaros que formáis parte de un equipo que esta trabajando en una tienda on-line, pensad en respuestas imaginarias a las tres preguntas.
  • Recibiréis dos fichas, una de ella con un objetivo secreto. Durante el ejercicio comportaros en algún momento de forma disfuncional como dicta el objetivo secreto.
  • Si el Scrum Master interviene en la disfunción no persistas.
Y adelante, Scrum Master a por la reunión diaria, a lidiar con esos miembros que van a boicotearla :-) Al terminar el ejercicio hacer una ronda de cuestiones y conclusiones finales:
  • ¿Qué comportamientos habéis observado?
  • ¿Cómo viviste el ejercicio?
  • ¿Qué ideas tienes para Scrum Master?
  • ¿Qué te dice esto sobre el rol del Scrum Master?