Quizá alguna vez te has visto envuelto en una discusión parecida. Entra un desarrollador nuevo o hay que renovar el ordenador de uno de los desarrolladores y toca pedir uno. Entonces la persona encargada de compras puede intentar ahorrar y puede preguntar cosas como «¿Con un I5 es suficiente, no?»

Voy a intentar explicar un poco por qué es muy peligroso ahorrar en cosas de este tipo:

Imaginemos una empresa de desarrollo normal, una PYME, con unos gastos medios de 100.000 € al mes. Este gasto incluye equipo de comerciales, administración, marketing, operaciones y por supuesto desarrollo.Incluye tanto gastos en personal como gastos de instalaciónes y gestión. La cantidad de pasta que necesita la empresa para producir y vender  su producto, en nuestro caso software, son 100.000 euros mensuales.

 

Ahora vamos a pensar en qué departamento es el cuello de botella, es decir, qué equipo es el que determina qué cantidad de producto llega al cliente final. Lo normal en una empresa de desarrollo de software que va más o menos bien es que el cuello de botella sea el equipo de desarrollo. Si se desarrolla más rápido cuando se tiene un proyecto para un cliente, se cobrará antes y se podrá empezar antes con otro proyecto. Si se desarrolla producto, contando con una buena elección de producto y características, se cuenta con que cuanto más se desarrolle, mejor es el producto y más vende.

La Teoría de las Restricciones nos dice que la productividad total de una empresa está limitada por la productividad del cuello de botella. Si el cuello de botella, en nuestro caso el departamento de desarrollo, incrementa un 1% su productividad, es la empresa completa la que incrementa su productividad un 1%. Lo mismo ocurre al contrario, si la productividad decrece un 1%, es la productividad de la empresa al completo la que decrece.

Teniendo en cuenta que para conseguir esa productividad, esa cantidad de producto vendido al cliente, la empresa gasta 100.000 € al mes, es lógico pensar que cada 1% de productividad le cuesta 1.000€ al mes a las arcas. Un 1% de productividad perdido por una herramienta de bajo coste, en nuestro caso un ordenador barato, alargada por la vida útil del mismo, digamos 2 años, resulta en 12.000€ de productividad perdidos. Todo por haber comprado un portátil de 400€ del Media Markt.

Después detodo esto…,  ¿Empezamos a hablar de discos duros SSD?

Como buen seguidor de David Bonilla, este ultimo domingo le leí su Bonilista. Hablaba de hacer un Fred Wilson, es decir, escribir un post cada día aunque sólo sea para comentar un vídeo de Youtube que has encontrado.

Yo sé que no voy a poder escribir un post cada día pero sí que voy a intentar escribir un poco más aunque sea corto. Este primero se llama:

Trivial Interno de empresa

Hace tiempo que detectaba que no todo el mundo en la empresa conocía bien los productos que desarrollamos. Hace falta que todos: comerciales, marketing, operaciones, soporte,… sepan bien todo lo que hacen y todo lo que NO hacen.

Para ello, y como buen conocedor de Gamification, ideé una pregunta diaría que lanzaría a la empresa usando Salesforce. Cada día creo una encuesta de Salesforce con una pregunta y 4 o 5 respuestas. Al día siguiente escribo como comentarios la respuesta correcta felicitando a los ganadores.

Llevo ya tres semanas y de momento no se me han acabado las ideas. Las mejoras preguntas son las que despejan dudas recurrentes que su ignorancia pueden llevar a un problema mayor. Sobre todo está funcionando muy bien al crear todos los días un pequeño debate y por la curiosidad que crea.

Como mejoras estoy pensando usar otro sistema web de preguntas en las que pueda ver quien ha respondido. De este modo hacer un sistema de Gamification con cara y ojos. Tabla de puntos con lider por departamento, recompensas,… De momento estoy contento con el resultado porque el objetivo que tenía lo he cumplido. Mejorar el conocimiento interno de los productos.

Casi todo lo pensado y escrito sobre Metodologías Ágiles y sobre todo Scrum, está pensado para un equipo, un producto y o un cliente o un grupo homogéneo de clientes. Sin embargo hay muchos equipos de desarrollo que tienen que lidiar con muchos clientes a la vez y en fechas dispares y cambiantes. Incluso teniendo una línea de producto determinada, siempre hay clientes que piden ajustes y desarrollos a medida. Empresas como Sony o VSN llaman a estos desarrollos Tokurens.

Existe un radiador de información que se llama Mapas de historias de usuario. En este diagrama se muestran horizontalmente historias de usuario relacionadas entre sí porque persiguen un mismo propósito o historía más grande y se ordenan verticamente las prioridades entre estos grupos de historias. Permite ver de un sólo vistazo lo que hay que desarrollar y elegir las historias que ofrezcan mayor valor posible.

Para mostrar la misma información cuando se está trabajando con multiples proyectos a la vez y no perder el alcance de cada uno se puede usar la misma idea y  hacer un Mapa de Historias de Proyecto.

Verticalmente se listan los proyectos en orden de fecha de finalizacion ascendente y horizontalmente las historias que se tienen que desarrollar para cada proyecto por orden de prioridad descendiente. La primera etiqueta será el nombre del cliente, seguidamente estarán las historias y al final una etiqueta con la fecha de entrega.  Si se hace entrega por iteraciones, junto a la fecha de entrega podemos escribir la iteración en la cual debería estar todo completado.

Para todo padre novel siempre llega el momento en el que te planteas si dejar a tu nenito o nenita que duerma en su propia habitación o si dejar que siga durmiendo en vuestra cama. Como para opiniones, colores, cada persona con la que hables seguro que está siguiendo el consejo de algun libro, pedriatra, médico. Normalmente los consejos vienen de uno de estos tres autores.

Voy a intentar ser lo más imparcial que pueda y dar pequeñas pinceladas de cada uno de los autores. He sacado la información de las propias entrevistas y páginas personales de los autores. Si hay algún dato incierto o sesgado, hazmelo saber en algun comentario y lo investigaré.

Eduard Estivill

Médico especialista en alteraciones del sueño. Autor de numerosos libros entre ellos el que más repercusión ha causado: «Duermete Niño» en 2003. En él  explica un método para conseguir que el niño duerma por sí mismo en su propia cama.

En el libro se explica minuciosamente cómo lograr que el niño identifique la oscuridad de su habitación, y un peluche,  (por ejemplo) con la hora de irse a dormir. Después de cenar, Estivill recomienda pasar unos 10 minutos con el niño, antes de llevarle a la habitación. Una vez allí, es importante que los padres no se conviertan en «elementos externos asociados al sueño», para ello deben salir de la habitación antes de que el bebé se quede dormido: «No podéis ayudarle a conciliar el sueño meciéndole, acariciándole o haciéndole mimitos», señala el autor. Ésta es tal vez la fase más dura para los padres («los dos primeros días de tratamiento son duros», advierte Estivill). El método establece una tablas de tiempo para realizar pequeñas visitas al dormitorio para tranquilizar al niño si este llora. Durante estas visitas, en ningún caso los padres cogerán en brazos al niño, ni le mecerás, simplemente, hay que tranquilizar al niño, haciéndole saber con voz firme que no está sólo.

«Sin duda. Si el niño no aprende a dormir, entre los cinco y los 14 años sufrirá otro tipo de insomnios, se mostrarán inseguros a la hora de dormir no querrán pasar la noche en casa de amigos, seguirán acudiendo a la cama de los padres… Esto se debe a que estos niños arrastran un mal hábito porque nadie les ha enseñado a dormir»

El método está basado en el Método Ferber. En la wikipedia en inglés se puede tener un resumen del procedimiento.

• Haz una preparación antes de llevar al niño a la cama. Esto incluye actividades rutinarias.
• A la hora de dormir, deja al niño en su cama y abandona la habitación.
• Vuelve a intervalos a la habitación a confortarlo (sin cogerlo/a). Por ejemplo, en la primera noche, se recomienda volver a los 3 minutos, despues a los 6, entonces 10 y así hasta que se duerme.
• Cada noche, vuelve a intervalos cada vez más largos que la anterior. Por ejemplo, la segunda noche puedes empezar por 5 minutos, entonces 10, 12 y así hasta que se duerme

Carlos Gonzalez

Pediatra y fundador de la asociación Catalana Pro-Lactancia Materna. Especialista en lactancia materna por la Universidad de Londres. Uno de los máximos exponentes en metodos no conductistas, conocidas como crianza de apego. Uno de los libros de mayor acogida fue «Bésame mucho, cómo criar a tus hijos con amor«, el mismo año que el libro de Estivill  (2003)

Citas obtenidas de entrevistas:

«Es muy importante que aprendan desde pequeñitos a dormir acompañados, porque así es como solemos dormir los adultos. Imagínate que no aprende a dormir con otras personas, y que cuando sea mayor no se quiere acostar con su marido. ¡Sería terrible! ¡No la conseguirías casar!»

«pienso que aquellos niños que desde el nacimiento han dormido solos se sienten más inseguros, y que su evolución es precisamente la contraria.»

«Los pediatras no son más que un reflejo de la sociedad. Sus malos consejos son similares a los malos consejos de familiares y amigos, y reflejan en gran parte su propia experiencia personal con sus propios hijos. Ahora hay doctoras que dan el pecho dos años y duermen con sus hijos, evidentemente sus consejos serán muy diferentes.»

Pregunta: «Mi bebé prácticamente tiene que estar conmigo prácticamente todo el rato, o para tomar teta, para dormir..»

Respuesta: «Los bebés necesitan atención constante, 24 horas. Es lo normal. Por eso la mayor parte de las madres del mundo llevan a sus bebés colgados a la espalda»

Pregunta: «Buenos días. Tengo un hijo de casi 3 años que necesita para dormir que esté a su lado y cuando se queda dormido ya lo puedo dejar solo, hasta ahora no tenía problema ninguno pero me preocupa el que ahora estoy embarazada de nuevo y cuando llegue el bebé mi hijo debería saber dormir solo...»

Respuesta: «Bueno, si está usted sola, cabrán los tres en la cama sin problemas. Lo importante es que la madre esté en medio, porque uno de tres años podría golpear sin querer al recién nacido….»

Pregunta: «.. lactación materna exclusiva hasta los 6 meses, ya que en el caso de mis dos hijos, me han aconsejado introducir los cereales sin gluten a los 4 y la fruta a los 5 meses...»

Respuesta: «Bueno, algunos pediatras todavía están dando recomendaciones antiguas.
Es comprensible. La alimentación no es una cuestión médica. El pediatra no es ni cocinero ni ama de casa. Procura estar al día de las novedades en el diagnóstico y tratamiento de las enfermedades, que es su profesión.»

Rosa Jové,

Licenciada en Psicología por la Universidad Autónoma de Barcelona, está especializada en psicología clínica infantil y juvenil y en psicopediatría (bebés de 0 a 3 años). Igualmente es licenciada en Historia y Geografía con especialización en antropología de la crianza. Autora del libro «Dormir sin lágrimas» publicado en 2007.

«No hay diferencia de éxito entre los métodos que enseñan a dormir a base de dejar llorar mediante una tabla y los que simplemente dejan llorar. Si la hay entre aplicarlo antes de los 18 meses o después», escribe esta especialista en el sueño. Para Jové, los métodos de adiestramiento no enseñan a dormir, «solamente provocan un shock emocional que altera los niveles de las principales hormonas que regulan nuestras emociones, y además le demuestran que no vale la pena quejarse porque nadie les responderá. Por eso funciona mejor en niños pequeños, ya que son los que tienen más posibilidad de shock».

«Todos los métodos de adiestramiento para dormir niños basados en dejarles llorar según una tabla me parecen crueles. Aaunque no llegaran a dejar ninguna secuela psicológica en el niño, pienso que estamos en una sociedad en la que el fin nunca justifica los medios y en ese sentido, dejar llorar a un niño, aunque sea para dormir, no me parece bien»

«Si un niño de seis años todavía necesita compañía de sus padres para dormir es porque le cuesta estar relajado para iniciar el sueño y necesita una figura conocida para tranquilizarse. Pueden hacer dos cosas, una de ellas dejarlo tal cual porque evidentemente el niño un día u otro se va a quedar dormido solo, pero si quieren adelantar ese momento, lo que pueden hacer es intentar relajar al niño antes de ir a dormir»

«Si el niño no ha dormido habitualmente en la cuna, evidentemente ese cambio hay que hacerlo gradualmente porque si no el niño podría no aceptarlo bien en los primeros días. Sobre lo de que se duerma en brazos, no es ni un buen hábito ni un mal hábito, simplememnte si el niños se acostumbra, el niño lo va a dejar cuando sea mayor otra cosa es que antes de ese momento los padres lo quieran dejar antes, porque pesa, y entonces ellos mismos tendrán que ir deshabituándole.»

En una entrada de blog que escribe la propia autora habla de 4 estudios (Spitz, Harlow, Bolwby, Mckenna) como pruebas de que lo que se hace en el metodo Estivil puede causar secuelas. Me he molestado en buscar cada uno de estos cuatro estudios.

Rene Spitz:  (1887-1974).

Psicoanalista americano nacido en Hungría. Spitz desarrolló el termino depresión anaclitica por separación emocional parcial  (la perdida de una persona amada). Cuando la persona perdida vuelve al niño en un periodo de 3 a cinco meses, se recupera el niño en su estado normal. Si se aparta más de cinco meses, empiezan a mostar los sintomas de deterorizacion seria. Spitz llamó a esto deprivacion total. En este enlace hay un vídeo que pone los pelos de punta sobre niños apartados de su madre durante largos periodos. No apto para corazones sensibles. Aparetemente este estudio no tiene relación con el método Estivill.

Harry Harlow: (1905-1981).

Psicologo americano conocido sobre todo por sus experimentos de separación maternal y aislacion social en monos. Estos experimentos demostraton la importancia del afecto y la compañia para el desarrollo social y cognitivo. Los experimentos del Harlow fueron controvertidos. Incluian meter a pequeños macacos en camaras de aislamiento hasta 24 meses. Estos salieron de las cámaras severamente afectados. Es un estudio similar al de Spitz pero en simios. Menor relación si cabe con el método Estivill.

John Bowlby(1907-1990).

Psicoanalista. En 1951 expuso que la maternidad es inutil si se retrasa hasta despues de 2 años y medios o 3. Para la mayoria de los niños, si se retrasa hasta despues de los 12 meses, existe un periodo critico. Si la figura de apego se rompe durante el perido critico de los dos años el niño sufrirá daños irreversibles consecuencia de esta separacion maternal. Un estudio tambien similar al de Spitz.

James McKenna

Como director del Laboratorio de  Notre Dame’s Mother-Baby Behavioral Sleep, es conocido por hacer los primeros estudios psicologicos y de comportamiento sobre las diferencias del dormir en solitario o con los padres. McKenna es un acerrimo defensor del colecho y centra su investigacion en la relacion entre situaciones al dormir, metodos de alimentacion y factores de riesgo del sindrome de muerte súbita . Puedes leer aquí el estudio (en inglés). Este estudio sí tiene relación con el tema del sueño y parece  muy interesante pero sigue sin relacionarse con los posibles problemas que apunta Rosa Jové sobre  dejar llorar al niño durante minutos hasta que se duerme. Si alguien ve esta relación, por favor que  me envíe la referencia y actualizo el comentario gustosamente.

Opinón personal (ahora sí)

En este aspecto cada uno es libre de tomar sus propias decisiones. Sobre todo hay que estar abierto a otras opiniones y no tomar como dogma ninguna de ellas. Habrá padres que prefieran vivir la paternidad lo máximo posible y por las noches  y  llevar a los niños a sus camas  y hay otros que prefieren  vivir la paternidad lo máximo posible y  tener  a sus hijos en sus camas.

Fuentes:

http://www.elmundo.es/encuentros/invitados/2006/06/2070/

http://comunidad.diarioinformacion.com/entrevista-chat/3196/Salud/Carlos-Gonzalez/entrevista.html

http://www.elmundo.es/elmundosalud/2003/01/28/pediatria/1043756488.html

Acabo de escribir ya un post sobre unas reflexiones que he tenido despues de la conferencia. Como lo tengo todo muy vivo en mi memoria quiero escribir aqui lo que más me ha llamado la atención y lo que me ha resultado más util. Así lo tengo guardado yo y lo comparto por si a alguien más tambien le interesa.

Empezamos con la keynote de Xavier Quesada. Habla del agilismo como esperanza para salir de la crisis. Un giro hacia la calidad, calidad que no genere «Failure Demand» (trabajo generado por errores). Focalizarse en trabajo no productivo para eliminar sus causas. Voy a usar la ideal del tablón donde escribir en qué se ha desperdiciado el tiempo de los desarrolladores y evaluarlo en la retrospectiva.También habló del ultimo momento responsable, hay que retrasar la decisión lo más posible para tener la mayor información.

Después me fuí al Workshop Kaizen. Juan Felipe Pons, un experto en Lean para construcción, que está visitando a todos los expertos mundiales en el tema.  Explica como se puede modelar el flujo de valor, todas las ramas y ciclos de elementos que pasan de departamento en departamente o al cliente para optimizar ese flujo como un todo.

Sigo en el track verde y empieza la charla sobre equipos autoorganizados. Me ha resultado útil  ver que exisite un progreso medible y un trabajo para logar equipos autoorganizados. No es algo que salga de la noche a la mañana pero existen métodos para ello.

Nos vamos a comer paellas ágiles. Lo de ágil no sé si era por lo de hacerlo de pié. Esto quizá fue un error porque no se pudo disfrutar del plato de arroz al ser complicado comerlo sin sentarse.

La charla «7 ideas para mejorar tu equipo ágil» quizá para mi fue la más flojita. Resultó curioso el tema del teletrabajo y que hay que mimar al teletrabajador.

Después entró Enrique Comba con fondo de AC/DC. Hizo una entrada espectacular y la charla en sí para mí fue muy buena. Me sorprendió la aparición momentanea de Uncle Bob. Realmente hace falta un cambio de forma de pensar y hacer del cliente como parte del equipo en lugar de como el enemigo. Hace poco , cuando hablaba con un amigo me comentó lo mismo, hace falta centrarse en hacer ganar al cliente dinero para ganar uno mismo.

Después del café entró David Bonilla en acción. Me encanta su forma de ver el desarrollo (y que comparto). Hace mucho tiempo que sigo su blog y su tweet y puedo decir que en su charla también encantó al auditorio. He descubierto que soy un esclavo de las empresas que usan gamification como estrategia. Las puntuaciones, los rankings y las insignias hacen que compremos danones, viajemos en iberia, hagamos check-In de foursquare con mucho placer. Lo que veo dificil es poder elegir un baremo que sea justo para todos. Si se hace un ranking de builds rotos, el que más rompe no tiene por qué ser el peor desarrollador sino el que se come más marroles,  por ejemplo.

El viernes aparecí en la keynote de J.B. Rainsberger, usé toda mi capacidad de entender el inglés para no perdeme detalle de toda su experiencia.

En la charla de integracion continua vs controlada por Pablo Santos presentó el uso de branches por tarea como la manera más eficiente de trabajar en equipo. La ventaja que le veo principalmente es poder subir cambios a tu branch personal como forma de tener backup de tu codigo sin romper el build. No tengo claro que sea lo que necesitemos actualmente en mi oficina.

Después me fuí otra vez al trunk verde y escuché atentamente la charla de Vanesa Tejada sobre visual scrum. Muy útil el poder usar un sistema visual tambien para uso personal de Product Owner e incluso para el propio CEO.

Por terminar, el tema que creo que más aplicación directa puedo hacer. Gracias a Jose Ramón Diaz sé como mejorar las retrospectivas. Como resumen 3 cosas: haz que todos hablen desde el principio para que les sea más facil después, obten la causa raiz de los problemas (5 why’s o fishbone) y añade como tareas el resolverlos para que no queden en el olvido.

El próximo año lo veo dificil ya que es en Extremadura pero de momento tengo suficiente food for though para unos meses como mínimo.

Buenísima organización, gente increible y contenido utilisimo.

He pasado dos días increíbles en la Conferencia Agile Spain 2011. Felicidades tanto a la organización como a todos los ponentes por la calidad de sus charlas. Después de 24 horas y un par de reflexiones hay unas cosas que me gustaría compartir.

Lo que más me ha sorprendido es la capacidad de reírnos de nosotros mismos que he visto como común en todo agilista que ha asistido. Tanto los ponentes de las keynotes como Rainsberger  que se ríe de su nivel de español; los ponentes de las charlas como Enrique Comba se reía de si mismo cuando apareció como un mega-comercial psicodelico y David Bonilla que lo hace como nadie y mostró que en Atlassian eso es incluso una filosofía de trabajo. Todos y cada uno de nosotros tenemos gran capacidad de reírnos de nosotros mismos y para tener esa capacidad hay que tener otra que es casi más importante, la HUMILDAD. Sí, lo he escrito con mayúsculas.  No porque lo diga gritando sino porque hay que darle a la palabra la importancia que se merece.

Los agilistas tenemos la humildad suficiente para decir: «Sí. Cometemos errores programando, por eso lo primero que hacemos es el test»

Los agilistas tenemos la humildad suficiente para decir «Sí. Es posible que no entendamos bien lo que nos pides que te desarrollemos, por eso te lo vamos a enseñar lo antes posible y así nos lo puedes rechazar aun cuando estamos a tiempo».

Los agilistas tenemos la humildad suficiente para decir «No. No podemos llegar con todo lo que nos pides en la fecha indicada, por eso vamos a ir entregando lo más importante paulatinamente. Por favor, no insistas en tenerlo todo.  Si lo haces te haremos un producto de baja calidad»

Es posible que el  resto del mercado del desarrollo del software  diga que sí. Que sí que puede hacer todo lo que se pide en una calidad indiscutible y por supuesto en la fecha que necesita el cliente. Ese tipo de gente que vende desarrollo de software normalmente no se ríe de si misma y va siempre en trajes negros con gafas oscuras y pelos pincho (¿os suena?). Pronto hablaré del traje de negocios, lo que significa, lo que comunica por qué hay que evitarlo. Una vez me dijeron que si se va con traje a ver al cliente se puede cobrar más. Los clientes actualmente confían más en la profesionalidad del propio traje, da igual quien lo lleve. Espero que pronto cambie esa mentalidad y realmente se confíe más en gente que suele ir con camisetas de Spiderman. Esa gente que gasta su dinero y su tiempo en hacer su trabajo lo mejor posible y dar el máximo valor. Esa gente que se va a sentar al lado del cliente a ver cómo trabaja desde el primer momento y ofrecerle lo que realmente necesita.

En la conferencia he aprendido que ese cambio de mentalidad es posible y es necesario. Necesario para que España y el mundo salga de todas las crisis. Hagamoslo realidad entre todos y extendamos esta visión.

“Maduramos el día en que nos reímos francamente de nosotros mismos.”

Albert Einstein

Al fin llega la tercera parte de la charla de Potenciación de equipos. Vamos allá.

Para que un equipo esté equilibrado y dependa lo menos posible de personas externas a él que puedan convertirse en un obstaculo o un cuello de botella,  cada uno de estos roles deben identificarse para ejercitarlos y desarrollarlos entre todos los miembros del equipo.

• Coordinador: Coordina los esfuerzos de todos para alcanzar metas, aunque no ocupe el cargo de líder. Hay que evitar que una misma persona mantenga este rol durante mucho tiempo y se recomienda que se vaya rotando entre todos los miembros del equipo.
• Impulsor. Está lleno de energía, “empuja” a los demás para avanzar en el trabajo. Su optimismo y decisión para afrontar los retos hace ver al resto que cualquier cosa es posible.
• Creador. La persona creadora está llena de ideas,es fuente de propuestas y sugerencias originales y sencillas. Es importante que esta persona entienda perfectamente el ámbito del problema para que saque su máximo potencial.
• Evaluador. Analiza las ideas presentadas, valora sus pro y sus contra, proporciona instrumentos de análisis. En las reuniones se puede ver frecuentemente debates entre el creador y el evaluador que puede suelen acabar en soluciones muy buenas.
• Realizador. Es el organizador práctico que transforma las decisiones y estrategias en tareas definidas y realizables, que los miembros del equipo puedan manejar. Es el que tiene más claras las tareas en las que se descompone una historia de usuario y su papel es fundamental para plasmarlas en el kanban.
• Investigador. El que aporta ideas del “exterior” de la organización, su papel principal es evitar que el equipo se quede estancado. A veces se confunde con el “creador” pero, a diferencia de este, no aporta ideas originales, sino conocidas por sus lecturas, observaciones, u otras fuentes externas. Es el samurai del google, no hay ejemplo de código fuente  o solución a un problema que se le escape.
• Comunicador. El más sensible para identificar necesidades e inquietudes de los demás miembros.. Su instinto lo lleva a crear ideas en los demás, sirve de “puente” en el manejo de conflictos. Ayuda a disolver las discusiones entre dos personas que no entienden sus posturas entre sí, explicando a cada uno el punto de vista del otro.
• Detallista. Se preocupa por lo que puede estar mal hecho y por los detalles para asegurarse de que  nada se ha pasado por alto. Ayuda mucho en las revisiones finales de las historias de usuario porque siempre detecta el problema que a todo el mundo se le ha escapado.

El tema del lider en un equipo ágil siempre es tema de debate. ¿Tiene sentido un lider en un equipo autogestionado? Yo creo que siempre es útil una persona cuyo objetivo sea hacer lo posible para que el equipo sea productivo, esté unido y contento con su trabajo.

Esto requiere una serie de funciones:

• No dice qué hacer, pregunta. Encuentra las preguntas adecuadas para provocar las ideas en el equipo.
• Alienta la creatividad. No reprocha los fracasos ni las ideas extrañas. Lo contrario podría llevar a  que se los miembros de equipo autolimiten en sus ideas para prevenir «broncas». Todas las ideas son analizadas y evaluadas sin descartarlas por adelantado
• Alienta la participación. Todos los del equipo deben participar. El lider debe estar atentos a personas que no hablan, normalmente esta falta de palabras indica falta de entendimiento.
• Propone mejoraas (coach). Investiga en metodologías y las propone al equipo. Intenta mejorar el número de puntos a realizar por sprint.
• Les incluye en las decisiones que les afectan, por ejemplo, participan en la selección de personal que formará parte del equipo.
• Evita impedimentos (papel del Scrum Master)
• Se asegura que el equipo técnico este siempre en funcionamiento
• Se come las reuniones innecesarias para el equipo, las que no les aporta visión de producto.
• Hay una que no comenté en la reunion de Agile Alicante pero salió el tema en la cena posterior. El lider debe aislar al equipo de las tensiones que puede haber en el resto de la empresa. Debe hacer de escudo de toda la negatividad para que el clima en el equipo de desarrollo sea favorable a la creatividad y la calidad técnica.

Antes de terminar quisiera recomendar dos libros que me han encantado y que hablan de la psicología del equipo son dos:

– Management Rewired (del que ya hablé en otro post)
– Peopleware. No se puede llevar un equipo de desarrollo sin leerlo.

Después de una semana mortal de trabajo vuelvo a estar en posesión de mi tiempo. Voy a continuar con la exposición que di en la sesión de Agile Alicante el 13 de Mayo. Puedes ver la primera parte aquí.

Cuando trabajamos con un equipo, ya sea de desarrollo de software o en otros entornos, no hay que olvidar que este equipo tiene una serie de necesidades. Prestar atención a cada una de ellas es importante como lider de équipo para desarrollarlo y sacar el mejor partido de él.

Si queremos que el equipo esté motivado, que sea capaz de juntar su esfuerzo con el de los compañeros para conseguir un objetivo común, no hay que olvidar que todos los miembros deben tener una visión global y clara de ese objetivo. El Product Owner es el responsable de que el equipo tenga una visión de alto nivel del producto a desarrollar. Con visión de alto nivel me refiero a que hay que evitar el dar visiones parciales sólo a los desarrolladores que van a realizar cada pequeña parte. Cuando el equipo conoce perfectamente qué tipo de software va a realizar, quién van a ser los usuarios, cual es la competencia,etc..  se produce la verdadera generación de ideas que hace de un producto algo innovador y de gran calidad.

Un error común que se suele cometer, es que los desarrolladores sólo conocen los problemas del software ya son los que tienen que resolverlos o ayudar a resolverlos. Sin embargo, elementos como el número de horas sin incidencias, el número de usuarios concurrentes que lo han usado sin causar saturación u otros elementos positivos, normalmente no llegan a oidos de los desarrolladores. Estos elementos positivos son un potente aglutinador que mantiene al equipo unido y motivado y con fuerzas para superar nuevos retos.

El entorno fisico en el que trabaja el equipo tiene mucho que ver con cómolos miembros se sienten parte de ese equipo . Los cubículos que aun parece que se usan en algunos entornos hay que descartarlos completamente. La ubicación de los puestos de trabajo debe fomentar una colaboración directa cara a cara. El equipo además debe disponer de una zona común para realizar el daily, juntarse para analizar los problemas, … Sin embargo no hay que olvidar que el trabajo tambien requiere concentración. El equipo debe disponer de elementos  para indicar que un miembro está en estado de concentración. Quienes conocen la técnica pomodoro sabrán que es importante que durante los 25 minutos de trabajo intenso no se reciba interrupciones. Hace poco descubrí el CherryTomato que marca en el skype con el estado «Do Not Disturb» durante el tiempo del pomodoro. Esto sirve para que el resto del equipo sepa facilmente si  es momento de hacerte las preguntas o si se las apunta para después.

El equipo además necesita de elementos de gestion visual. El kanban es un buen elemento para que se auto-gestionen el progreso de los proyectos y se asignen el trabajo a sí mismo. Les permite encontrar los cuellos de botellas y resolverlos ellos mismos.

El equipo debe ser multidisciplinar y multinivel. Esto no quiere decir que cada miembro del equipo debe ser multidisciplinar y dominarlo todo sino que las especialidades combinadas de los miembros forma la capacidad de equipo que los proyectos necesitan. Tampoco hay que ver a los miembros como clones entre sí sino cada uno puede tener distintas capacidades, personalidades y necesidades. Esto último normalmente se omite cuando se piensa en un equipo. Puede haber un miembro que necesite doble monitor mientras que otro necesite una impresora cerca. Aunque cada miembro trabaje primero en la parte que más conoce y controla, esto no quita que si ha acabado su parte  y quedan tareas pendientes para finalizar el sprint, se arremangue y las realice evitando así cuellos de botella. Hay que buscar la parte buena de la especializacion evitando que ocurra la negativa.

La semana que viene espero terminar la charla escrita.

En el momento de escribir esto hay un anuncio de una compañía de telefono que dice algo así como «Cuando algo es así de bueno, hay que compartirlo». Esto es lo que me ha pasado cuando he descubierto una aplicación que me ha parecido útil de verdad.

Sé que estoy escribiendo la charla de potenciación de equipos pero no puedo resistirme a hablar de esto. Además está muy relacionado con el tema. 😉

Hace tiempo ya que se viene comentando en el mundillo del desarrollo software acerca de la tecnica pomodoro, yo mismo escribí una entrada hace tiempo. Esta técnica recomienda hacer intervalos de 25 minutos de concentración y 5 de descanso. Tan sencillo pero a la vez tan dificil de hacer. Ya que esta técnica necesita de algo muy importante, que la gente que trabaje contigo respete tus pomodoros.

Hace más de un mes empecé a escribir (porque no encontré ninguna) una aplicación para gestionar pomodoros que permitiera ver si los compañeros están o no pomodoreando para no interrumpirles en mal momento. Pues me he enterado que esta aplicación ya existía. Se llama Cherrytomato y se puede encontrar aquí.

Esta aplicación se comunica con el skype, un invento más robatiempo que el teléfono. Cuando se empieza un pomodoro marca automáticamente el status de skype como «Do Not Disturb» y además pone como la frase del contacto algo como «Estoy ocupado hasta dentro de X minutos». Más claro, agua. Please no molestar.

Algo aparentemente sencillo pero a la vez tan útil. Uno es capaz de ver qué compañeros estan pomodoreando para esperar a que terminen y tus compañeros ya no tienen excusa tampoco para romper tus pomodoros. Como funcionalidad extra, esta aplicación cuando terminas el pomodoro te da un gráfico de intensidad de uso del teclado y ratón, así como las aplicaciones que has venido usando durante el pomodoro. Una gracia.

Voy a seguir usandolo y espero que lo usen mis compañeros para obtener  en el equipo las dos ventajas principales de la técnica pomodoro (productividad y felicidad)

Esta es la primera parte de una charla que di en la reunión e Mayo del Agile Alicante.

Parte I. Un poco de historia.

La primera necesidad de organizar un grupo de cientos o miles de personas fué en el ámbito militar. Era inviable que un general coordinara por sí mismo a todo el contingente por lo que hacía falta crear algun tipo de jerarquía. Ya en el ejercito romano, cada mando sólo daba ordenes a un máximo de 10 personas que a su vez cada uno daba a otros diez y así hasta llegar a todos los legionarios. Así surgen cargos como el decurion (10 legionarios) y el centurión (10 decuriones = 100 legionarios). La estructura jerarquica era más que necesaria. Sin embargo la comunicación puede alterarse  cuando atraviesa un nivel jerarquico, igual que ocurre en el juego del telefono loco cuando se pasa un mensaje de persona a persona.  El ejercito resuelve este problema con una diciplina estricta. El mensaje es transmitido y ejecutado palabra por palabra sin posibilidad de analizarlo ni modificarlo.

El auge del ferrocarril provocó  la necesidad de coordinar miles de personas en un fin común en el mundo empresarial. Pensilvania Railroad, por ejemplo tenía a más de 100.000 personas empleadas en distintos lugares del pais. Todas estas personas necesitaban coordinación y control. Harrington Emerson adaptó las estructuras militares al mundo de la empresa. Lo más importante en este tipo de organización es el contron en los trabajadores, no en el modo en el que el trabajo es realizado. Además, cada función o departamento se convierte en un feudo en sí mismo. Realiza su trabajo con una mínima comunicación con el resto de departamentos. El resultado del trabajo es «lanzado» de departamento a departamento, y acaba variandose respecto a lo solicitado si se encuentran problemas en las fases anteriores o es el jefe el que tiene que resolverlos. La motivación de los trabajadores en este tipo de organizaciones suele basarse en gran medida en el salario, siendo un problema a medio y largo plazo. Los mandos intermedios normalmente están bastante limitados por su mandos superiores y no tienen gran capacidad de decisión respecto a la gente que llevan.

Hay muchos mercados que necesitan un tipo de estructura más dinámica. Un tipo de estructura que responda a un proceso de selección natural. Si cada elemento realiza bien su trabajo es recompensado por el cliente sino no es requerido más. El foco se gira hacia el cliente completamente. Si un elemento del equipo necesita reciclarse y adaptarse para nuevas necesidades del mercado lo hará. Este tipo de organizaciones fue muy usada a mediados del siglo 19 en los Estados Unidos. Las formaban pequeños emprendedores autonomos que se contratan unos a otros para dar una mejor respuesta al cliente. Así por ejemplo el propietario de las ovejas contrataba al mejor esquilador, despues al que mejor trataba la lana y de este modo  realizaba un producto de gran calidad para el mercado.

En la parte 2 veremos una descripción de qué es un equipo multidisciplinar y qué necesidades tiene.