Scrum master a tiempo completo: 42 Tareas

Uno de los artículos que más referencio en mi formación en Scrum (Qué es Agile) cuando hablo de las labores del Scrum Master es: 42-tasks-for-a-scrum-masters-job. Por alguna razón, todo el mundo parece entender que el Product Owner es un trabajo a tiempo completo, o ser miembro de un equipo también, pero que probablemente el rol del Scrum Master puede ser realizado a media jornada o incluso menos.
El scrum master también tiene mucho trabajo en equipos medianos o grandes, o nuevos. Muchos de liderazgo. Y es preferible que se centre en sus tares como scrum master, compartiendo su trabajo entre dos equipos por ejemplo, que trabajar también con la gorra compartida de miembro del equipo. ¿Por qué? Por que las labores que tenderá hacer son las de desarrollador antes que las de scrum master.

He querido traducir este artículo, para que quede en castellano, con permiso de Bernd Schiffer, para que quede constancia, y pueda referenciarlo en nuestro idioma :)

Artículo original: 42 Tasks for a Scrum Master’s Job

Update: ¡Cómo va a cambiar con la Inteligencia Artificial! Impact of AI in organizational design

Las siguientes preguntas aparecen a menudo cuando realizo formaciones o consultorías en Scrum:

¿Por qué los roles de Scrum Master y Project Manager deberían ser llevados por personas diferentes? (Quora)
¿Será el Scrum Master una ocupación al 100% o puede un programador ocuparse de ello si tiene mucha experiencia en planificación ágil? (Quora) 

Tras estas preguntas está la suposición de que el Scrum Master no es un rol a tiempo completo. Quien hace esas preguntas conjeturan con la posibilidad de ahorrar dinero juntando dos roles en una sola persona.

Las preguntas son realizadas por novatos como Scrum Masters, por product owners, por miembros del equipo, por managers, por stakeholders de cualquier tipo. De los tres roles en Scrum, todos parecen inferir inmediatamente que ser miembro del equipo es un trabajo a tiempo completo -por que desarrollan software el día completo - y que ser un product owner es también a tiempo completo - por que desarrolla el producto todo el día-, pero parece difícil de imaginar cual es el trabajo de un Scrum Master pueda ser y el por qué diablos sería un trabajo a tiempo completo, también.

¿Quizás esos que preguntan no sepan que es lo que un scrum master hace todo el día?

Aquí presento una lista de 42 cosas que diría que son parte del trabajo de un scrum master:

Reuniones

- Facilitar reuniones para el equipo. Esto incluye:

   - Preparar

   - Moderar

   - Postprocesar

 - Realizar retrospectivas, que son especiales, por consiguiente las cuento separádamente.

Dinámicas de equipo

 - Realizar coaching a los miembros del equipo (p. ej. coaching 1a1)

 - Mediar en los conflictos

 - Ayudar al equipo en la toma de decisiones

 - Fomentar la auto-organización del equipo

 - Mediar en el conflicto de objetivos entre el equipo de desarrollo (alta calidad técnica) y el product owner (más funcionalidad)

Aprendizaje

 - Continuar aprendiendo todo lo relativo a Agile (p. ej. visitar grupos de comunidades, atender a conferencias, leer libros, escribir blogs,…)

 - Asesorar a los miembros del equipo en todo lo relacionado con Agile.

 - Ayudar al equipo a crear radiadores de información.

 - Dar feedback al equipo.

 - Fomentar el uso de prácticas de ingeniería ágiles dentro del equipo de desarrollo (esto es un enorme trabajo para invertir el tiempo de un Scrum Master, incluyendo por ejemplo, publicación/releases automáticas, entrega continua, TDD, y muchos más).

 - Desafiar al equipo con nuevas ideas sobre Agile Management (p. ej. FedEx -Days).

 - Colaborar constantemente con otros Scrum Master en la organización (p. ej. a través de la comunidad de práctica).

 - Bajar al Gemba.

Producto

 - Ayudar a escribir o dividir historias de usuario.

 - Ayudar a escribir o adaptar la visión del producto.

 - Ayudar a ordenar los elementos de la pila de producto.

 - Ayudar con la planificación del sprint.

 - Estar familiarizado con el trabajo del equipo (p. ej. el producto)

[Sobre producto hemos escrito Desarrollo de Producto y facilitación]

Visión general

 - Juntar a la gente que debería hablarse entre ellos.

 - Estar en contacto con los stakeholders regularmente.

 - Ayudar al equipo a informar a management.

 - Ayudar a fortalecer la comunidad ágil dentro de la organización

 - Organizar eventos de intercambio como Open Spaces o World Cafes para el equipo, stakeholders y el resto de la organización

 - Compartir ideas y análisis en la compañía (micro-blogging, blogging, conferencias internas,…)

 - Ser la persona de contacto para todos en el equipo y los stakeholders en todo lo concerniente a Agile. 

 - Dar oportunidades de aprendizaje a la gente en la organización (p.ej. charlas o talleres) y permitirles aprender conceptos Agile importantes como p.ej. la deuda técnica.

Cambio

 - Ayudar al equipo a eliminar impedimentos.

 - Sugerir nuevas métricas para el equipo como catalizadores del cambio

Espejo

 - Reflejar los valores ágiles y de scrum al equipo.

 - Recordar al equipo sus acuerdos (p.ej. políticas)

 - Ayudar al equipo a mejorar constantemente sus procesos.

 - Reflejar los problemas al equipo a través de la observación desde fuera.

 - Hacer preguntas abiertas.

 - Comprobar los modelos que usa el equipo (p.ej. sprint backlogs, métricas, etc.) y mostrarles las diferencias entre el modelo y el mundo real.

Varios

 - Ayudar al equipo a mantener el foco (p.ej. actuando como un buffer entre las distracciones externas y el equipo)

 - Ayudar al equipo a mantener sus herramientas scrum (paneles, pilas de acciones, gráficas, backlogs,…)

 - Ayudar al equip y el product owner para encontrar los adecuados:

    - Definición de terminado (DoD).

    - Definición de preparado (DoR).

¿Has hecho o considerado todo lo mencionado anteriormente? Tomate un respiro, ¡debes estar agotado!

     Creemos que el scrum master es un rol a tiempo completo para una persona en un equipo Scrum. Scrum Master Manifesto.

¿Interesado en mentoring de Scrum Master? 
Contacta -TAYARI-

Estimación ágil de proyectos (y 2): Equipo multiproyecto.

Hablábamos el "otro día" sobre la planificación ágil, y explicábamos el proceso para estimar un proyecto, y ver su evolución. Trabajábamos con la hipótesis de que era un proyecto para un equipo, un entorno que no siempre se da en las empresas.
El mecanismo que aplicamos en un entorno multiproyecto es básicamente el mismo, pero contamos con una nueva incógnita: la dedicación del equipo a cada proyecto.

Sabemos lo perjudicial que es para nuestra cabeza la multitarea, lo negativo que es para un equipo el multiproyecto y lo fatal para una organización la pérdida de foco y capacidad de ejecución. Sin embargo, en muchos entornos, se sigue empezando cualquier proyecto que se nos pase por la cabeza, antes que priorizarlos claramente y dedicar energías a aquello que nos aporta más valor. Este es un tema muy importante, y que influye poderosamente en la capacidad de trabajo de una organización.

Así que, si trabajas en un equipo multiproyecto, las posibilidades de tener un buen lío son abundantes. Y la estimación va a depender tanto o más de gerencia como del equipo. ¿por qué? Simplemente por que si la dedicación no es conocida, o no es sostenida, no puedes estimar. Así que añadimos una nueva hipótesis a la hora de dar fechas. Y es arriesgada, probablemente no cae en la responsabilidad del equipo.

Si decides trabajar en multiproyecto (recuerda, es una decisión, quizás no es tuya, pero es de alguien) a la hora de estimar, deberás asignar un porcentaje de dedicación a cada proyecto. Si tienes datos históricos de porcentajes de puntos historia por proyecto, te podrán ayudar a trabajar con una hipótesis lo más cercana a la realidad posible.

El mito de la organización ágil (presentado en la CAS2012)

Este post es la explicación de mi presentación en la conferencia Agile-Spain 2012. Podeis encontrar la presentación en slideshare: El mito de la organización ágil.

Cuando hablamos de organizaciones ágiles, podemos hablar ya de varios modelos sobre los que se está trabajando, como por ejemplo:

• La organización conectada, de Dave Gray. Nos muestra una organización como una serie de células, equipos aut
• El modelo de BetaCodex, de Niels Pflaeging, en donde insiste en que el management es innecesario, y habla de dos niveles, donde unos atienden al mercado, y otros dan servicios centrales, también como organización de equipos autoorganizados.

Sin embargo, no es de los modelos de lo que quiero hablar, si no de lo que nos mueve a hablar de organizaciones ágiles. A pequeña escala, a mi me transformó la idea ya comentada en este blog de que Equipo = Producto. Esta simple igualdad me hizo cambiar el chip, como responsable de equipos, desde la visión de construir software, a construir equipos capaces de hacerlo. Y ser consciente que lo bueno que fuesen los equipos, así sería el producto que produjesen.

A nivel organizativo podemos escalarlo exactamente igual, y ya había una Ley que lo enunciaba:

Ley de Conway:
Las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones.

Es decir, si tu organización es una basura, solo generará más basura.

Todos conocemos casos donde las organizaciones son el principal problema de la gente que se encuentra dentro de ellas. Solo tenemos que echar un vistazo a TrabajoBasura.com para observar cómo se han convertido en un verdadero problema para muchas personas.

¿qué clase de decisiones toman las organizaciones de hoy en día que nos han llevado a tenerlas como fuente de muchos problemas? ¿cuando descolgarán el teléfono de su conciencia?

NUNCA. Nunca lo harán, básicamente, por que las organizaciones NO existen. No hay nada en lo que nos podamos excusar para hacer/no hacer algo echando la culpa a una "organización". No hacemos nada por la "organización". Como ente jurídico tendrá algo de sentido, pero no en realidad, es solo una abstracción, una metáfora. ¿dónde está la organización en vuestras reuniones?

Una organización está compuesta "simplemente" de RELACIONES. Tenemos que entender qué ata a las personas para actuar cómo actúan  Entonces empezaremos a comprender ese sistema que llamamos organización. Estamos atados a otras personas, a hechos sucedidos o por suceder, y a sentimientos como el miedo o la ilusión. Esa maraña de hilos forma un sistema complejo que debemos tratar de cambiar, actuando sobre las relaciones tanto como sobre las personas.

Generalmente las organizaciones parece que nos arrollan cuando queremos realizar alguna iniciativa de cambio. Debemos conocer qué ata a cada persona dentro de un sistema para poder entenderla. Movernos a una organización ágil no será cuestión tan simple como implantar un modelo o metodología. Igual que implantar Scrum en un equipo no es tan solo hacer las reuniones y artefactos, una organización ágil debe compartir misión, principios y valores:

• Una misión: Las personas necesitamos saber el POR QUÉ. Aquello que nos mueve y nos guía. Una misión compartida creará una dirección por la que identificamos que debemos movernos. Y puede haber varias escalas de misiones, como cuando en mi pequeño equipo en Biko hacíamos retrospectivas anuales para decidirlas, o les ponía retos como convertirnos en el "mejor equipo de desarrollo de Gipuzkoa"
• Con autonomía y respeto: La autonomía es básica para poder llegar a tener equipos autoorganizados, y el respeto la base para ello. Desarrollar productos debe empezar por desarrollar y permitirle hacerlo a las personas involucradas. Son la gente que debe aprender. Se deben crear equipos capaces de definirse sus objetivos, y capaces de conseguirlos.
• Sumando diferencias: La creatividad juega un papel muy importante en nuestras organizaciones hoy en día. Nunca sabes quien puede aportar la idea brillante o sorprendente. No solo ya las cuestiones técnicas son básicas, si no que las habilidades sociales se han vuelto imprescindibles en la nueva economía.
• Con absoluta transparencia: La transparencia se convierte en una vara de medir. Si algo te da miedo a ser transparente, es posible que no vaya alineado con una organización ágil. Es un valor básica para la autonomía de los equipos, para que la información fluya entre todas las relaciones personales sin crear silos ni malentendidos.
• Donde el dinero es una consecuencia: Las organizaciones deben ser rentables y conseguir beneficios, ¡sin duda! Estamos diciendo que la consecuencia de gente motivada, con una misión, trabajando por resultados, que se autoorganiza, va a ser conseguir beneficios.

Las personas que trabajamos en un entorno como el desarrollo de software, nos vemos completamente influenciadas por el entorno en el que lo hacemos. De hecho, creo que somos el sector laboral en el que más nos afecta. Nuestro trabajo es el más intangible, y el menos técnico en realidad (¡de verdad!). La mayoría de nuestros problemas en los proyectos no son técnicos, son sociales, de comunicación, de colaboración. Y es por ello que el mundo "Agile" se está volviendo tanto hacia las organizaciones.

Y debemos mirar también alrededor nuestra, y sumar fuerzas con muchos movimientos que vienen hablando de las nuevas formas organizacionales desde otras perspectivas. Creo que será enriquecedor para todos conectar con las ideas de Lean, Worldblu o Koldo Saratxaga entre otros.

Mención especial merece, bajo mi punto de vista, el llamado "Culture Hacking". La idea es que el mismo movimiento ágil es un hack de la cultura: procedimientos y valores que podemos usar para cambiar nuestras organizaciones.
En definitiva, las organizaciones ágiles quizás no se diferencien demasiado en su estructura organizativa de las actuales (que lo harán), si no por el cambio de mentalidad en la búsqueda de la creación de equipos autoorganizados, en la visión de cada y una de las personas del sistema global, y en métricas añadidas a las financieras, como la satisfacción de cualquier persona relacionada con esa organización, interna o externa. No importará el "dibujo" de tu organización, si no el tipo de relaciones que vamos a crear diferentes entre las personas.

No olvidemos que podemos cambiar aquello que nos incomoda o molesta, mejorar nuestro mundo alrededor. Espero veros en la CAS2013 ;)

Escuchando a la comunidad, a la gente, a los alumnos

Estos dos últimos meses hemos pasado mi amiga @jessi_aguado y yo por tres universidades, proyectando nuestra visión del desarrollo de software, del agilismo, y básicamente, de buena parte de entender nuestra vida. En principio nos invitaron de la FISS de Donosti para dar una charla sobre metodologías ágiles, y de ahí, por una pequeña casualidad, Amalia (@amaliahern) me comentó de ir a Burgos a dar una charla con la misma idea: hablar a los alumnos sobre las metodologías ágiles. Así que amortizábamos un poquito más la charla y la dábamos dos veces. Finalmente, el día que la dimos en San Sebastian, nos invitaron también a Bilbao, así que ha sido un auténtico Agile Tour Universidades para nosotros. Jessi nos cuenta con mucho más detalle en su blog en su particular crónica.

Esta es una de las cosas más agradecidas de cuando empiezas a trabajar para la comunidad. Al empezar a formar Agile-Spain, al ir a dar charlas en la Melee, a organizar conferencias a nivel nacional, al mover eventos locales,... siempre hay alguien que te pregunta: "¿y cuanto dinero ganas con eso?" Generalmente miro con cara de pena a quien me pregunta eso, porque tengo la impresión que se está perdiendo algo grande. No doy lecciones a nadie de lo que tiene que hacer, yo obtengo muchas satisfacciones de "trabajar" en un montón de historias que no me dan "pasta". Obtengo formación y aprendizaje, contactos, historias que contar,... pero también, y mejor aún, he hecho amigos, aventuras y tengo una sensación agradabilísima de haber hecho cosas importantes para la gente de alrededor.
Ahora como profesional autónomo he cambiado bastante la idea de lo que significa invertir el tiempo, y sacarle un rendimiento económico al mismo. ¡No queda más remedio! :) Pero hay otra serie de cosas que seguiré haciendo mientras mi ya justa disponibilidad me lo permita. Es puro egoismo en realidad, me proporciona mucha más satisfacción que trabajo dedicado :)

Os dejo a continuación la presentación, con explicaciones, preparada para los alumnos de universidad que quisieron venir a escucharnos. Intentamos que fuese una charla muy motivadora, hablando de lo que nos interesa, básicamente, ser felices en el trabajo.

La visión "ágil" del software para universitarios

View more documents from Jose Ramón Díaz

Organización ágil: de lo racional a la inspiración

En una organización ágil la cuestión que deberíamos creer es en las personas, que son capaces de hacer aquello que se proponen. Que son capaces de aprender para hacerlo. Y que tienen ganas de hacerlo.
Recientemente he leido un artículo, cuyo título es muy relevante: Knowledge workers respond to inspiration, not supervision. Y esa idea subyacente prevalece en el agilismo, en su manifiesto. Y responde a un principio básico de Lean: "Respeto a las personas".

Professionals require little direction and supervision.
What they require is protection and support.

Sin embargo, muchas veces actuamos más controlando el trabajo del resto de la organización, de nuestros subordinados, o incluso de los propios compañeros. Controlando en el sentido de querer que hagan las cosas como nosotros las haríamos. Esperando que respondan univocamente a nuestras órdenes o deseos, cuando no nos damos cuenta que es muy probable ni siquiera las hayamos expresado correctamente.
La pregunta que sale siempre tras este planteamiento es: ¿realmente podemos creer en todas las personas? Y si vemos que una persona no es capaz de seguir al resto, o boicotea al equipo, o simplemente consideramos que su rendimiento no es suficiente... ¿hasta cuando le tenemos que aguantar? La respuesta es muy sencilla... ¡depende! Intenta conocer las verdaderas motivaciones o problemas, el contexto que le mueve a comportarse de una manera u otra, y piensa primero por qué está sucediendo eso. La mayoría de las veces se le podrá poner remedio, y si no, soluciones drásticas en cuanto creas que no hay otra posibilidad. En una organización es cierto que hay una exigencia mínima, que de hecho es la que inicialmente crea el compromiso personal.
Un equipo es una pieza clave en el desarrollo de software, y las habilidades técnicas son tan importantes como las interpersonales. Tú, ¿de cual te olvidas?

Nueva etapa profesional: la inspiración

No sería capaz de reflejar mejor estos últimos cinco años trabajando en Biko de cómo ya los ha reflejado Jessi en su blog.

Va de personas que son felices en su trabajo. Porque el desarrollo de software no es trabajar con ordenadores y picar código. El desarrollo de software es mucho más: son personas haciendo cosas grandes que disfrutan con lo que hacen, y sobre todo, con quien lo hacen.

Este análisis agradece, mejor de lo que yo lo puedo hacer, a la gente maravillosa con la que he compartido tantos momentos. Gracias.

Naturalmente, yo tendería a realizar un análisis más frío, centrándome en los fallos para analizarlos y no volverlos a repetir. Contaría un poco lo que creo que han sido los éxitos y los fracasos de estos años. Pero lo que me ha cambiado últimamente es la percepción del éxito. Y no puedo sino pensar que estos últimos años lo han sido, aunque quizás desde cierta perspectiva no lo parezca.
Así que esta vez no haré un examen de conciencia público, básicamente por que creo que no sabría reflejarlo bien. No analizaría datos ni cifras, proyectos de éxito ni de fracaso. De todo hemos tenido, obviamente: unos proyectos bonitos, otros muy duros; proyectos que han salido genial, y proyectos, que casi morimos en el intento... Resulta que en esta ocasión el análisis que me sale de las tripas serían relaciones personales, sentimientos, intuiciones e inspiraciones. Y no acabaría nunca :) Esta vez he dicho lo que tenía que decir a las personas que se lo tenía que decir ;)

La cuestión es que me lanzo a una nueva etapa: dejo de ser empleado de Biko, aunque no abandono esta empresa. Ahora voy a colaborar con Biko. Cambio sutil en este caso, pero importante. Voy a ampliar horizontes. Me hago autónomo. Voy a empezar a trabajar en ideas nuevas. En estos momentos tengo planes muy concretos a corto y medio plazo, de los que os iré informando puntualmente. Busco la inspiración un poco más allá de mi zona de confort,... de hecho, mucho más allá :) Biko es una de las mejores empresas por la que podéis pasar, y seguiré unido a ella mientras me dejen ;) pero ha llegado el momento.
Seguro que podéis imaginar muchos de vosotros en qué área voy a trabajar ;) ¡metodologías ágiles! Pero si espero a tener preparada la web, mi portfolio de servicios de consultoría/coaching en metodologías ágiles, mi plan de marketing, etc. no lo anuncio nunca. Pero aunque no tenga todo eso, podéis ir preguntándome para contratarme desde YA ;D

De lo racional a la inspiración. He ahí mi nuevo lema.
Necesitamos más inspiración en este mundillo. Y menos control. Los "trabajadores del conocimiento" respondemos a la inspiración mucho mejor que a la supervisión. Vamos a demostrarlo.

Organización ágil

¿De qué hablamos cuando nos referimos a una organización ágil? ¿existe eso?
En general oigo que es la organización que se adapta a los procesos de creación de producto basados en equipos multidisciplinares que trabajan de manera ágil. Es decir, que con un enfoque bottom-up, creamos la organización ágil. Los equipos con la nueva manera de trabajar son "raros" y acaban demandando a su propia organización que se adapte para el mejor funcionamiento de todos.
Me suena un poco extraño. Generalmente la organización funciona como alguien ha impuesto, o ha establecido. Además, el cambio bottom-up lo veo limitado hasta que encuentras un escalón demasiado duro para seguir creciendo. Y la cultura se come la estrategia para merendar, que dicen.
La otra cuestión sería realizar el cambio desde arriba, pero entonces perdemos la perspectiva de lo que es el agilismo, pues lo ágil, estrictamente hablando viene de su manifiesto, escrito para el desarrollo de software, NO para la gestión de empresas. Y debemos basarnos en otras fuentes (Lean o las nuevas corrientes de gestión organizativa). Lo denominado ágil, se "inventó" en un manifiesto que trata del desarrollo de software. Es tan bonito y tan perfecto ;) que extraemos conclusiones que afectan a organizaciones enteras, pero ¿deberíamos hacerlo realmente?
¿qué claves nos da el manifiesto ágil para poder extenderse a toda una organización? Veamos los primeros puntos:
Valoramos 

• A los individuos y sus interacciones por encima de los procesos y las herramientas.
• Trasladado al mundo organizativo: Confianza, coordinación, respeto.
• El software que funciona por encima de la documentación exhaustiva
• Trasladado al mundo organizativo: Orientación a resultados
• La colaboración con el lcliente por encima de la negociación de contratos
• Trasladado al mundo organizativo: Colaboración, compromiso
• La respuesta al cambio, por encima del seguimiento de un plan
• Trasladado al mundo organizativo: Aprendizaje, adaptación

Es decir, tenemos que basar una organización en la confianza, la coordinación y colaboración entre personas que se respetan, orientadas a resultados y comprometidas con los mismos, que aprende y se adapta al medio. Sin duda son un montón de cosas molonas y de buen rollo, pero, ¿cómo se trasladan a una organización? Sin duda también, se puede realizar.
Más en próximos capítulos. Stay Tuned.

Agilismo a nivel táctico

Hace unos días discutíamos entre los "javeros" de Biko2 sobre las mejores prácticas, herramientas, librerías, automatizaciones que cada proyecto debería llevar en busca de la verdad, o sea, la calidad perfecta :)

Se empezó a hablar mucho de cuestiones concretas, y divagamos un poco sobre algunas herramientas o prácticas a incorporar o reforzar, que para eso nos encanta discutir como al que más. Estas cuestiones las asocio al nivel táctico de aplicación del agilismo en una organización, maniobras en corto plazo que son directamente aplicables para conseguir un fin sobre el campo de batalla. Pero me dio la impresión de que nos perdimos en siglas y nombres, y desglośe un poco por niveles lo que hallaba importante. Os extraigo pues un pedacito del email que envie en ese momento a mis compañeros, sobre los niveles de actuación para la calidad, como desarrolladores en labores técnicas:

• Programación: PMD o checkstyle (herramientas de análisis de código) nos ayudan a no cometer errores varios, aún teniendo que repasar las posibles reglas que pongamos. Pero cada linea que escribimos es una decisión que tomamos sobre la aplicación, y eso solo se resuelve con la inteligencia del desarrollador. Hay que saber cosas de SOLID, de gestión de excepciones, de gestión de logs,... etc. que NO SE PUEDEN AUTOMATIZAR.


• Ecosistema: El ecosistema nos puede comprobar que no rompemos el build, que tenemos buena cobertura de tests, que tenemos infraestrucutra pra hacer TDD, buenas métricas del sonar, despliegues automáticos, la gestion de merges/branches.... pero todo esto,no hay manera que nos lo haga solo... solo depende de la inteligencia, y ahora, también, el trabajo duro del desarrollador. Hay que saber de integración continua, de gestión de ramas,...


• Aplicación: A nivel aplicativo tenemos la definición de terminado-TER-MI-NA-DO, las pruebas de aceptación, o sea, la parte funcional. Aquí entra en juego lo anterior: la inteligencia y el trabajo duro, pero sobre todo, la responsabilidad y el compromiso del desarrollador, las ganas de hacer las cosas bien y emocionar al cliente.

Un saludo a mis colegas de Biko, que sé que me leen ;)

Quinto cumpleaños

Hoy hace cinco añitos este blog. Casi abandonado y en la pobreza de posts sobrevive a mi poca dedicación al mismo. Pensaba que este año había sido el más triste en el mundo Najaraba, pero ahora he visto que el 2007 fue incluso más parco en la publicación de posts.
Así que solo saludo al personal que siga leyendo este blog, y que informo que sigo vivo :)
Aunque este año ha ido bastante activo en otras areas de "lo ágil", publiqué un par de artículos, en REICIS y en CES Navarra. Di una charla en la Navarparty, y sobre todo, he colaborado en la fundación de agile-spain y su primer evento. Así que aunque no me leais mucho por este blog, podeis verme por otros lados.
Por otra parte, me da rabia no haber terminado mi serie sobre Lean, y no poder dedicar más tiempo a leer y comentar mis experiencias en el desarrollo de software.
Este año incluso me abrí una cuenta de twitter :) , y sobre todo, intento dedicarle mucho más tiempo a mi hijo!!
¡Os deseo un feliz 2010!

Equipos vs. personas

Si algo me gusta de Scrum como metodología ágil es que intenta sacar el máximo potencial a los equipos. Entendiendo equipo no como un grupo de personas que trabajan juntas, si no como un grupo de personas que comparten una visión y una motivación que les une con lazos especiales.
La medición de métricas en Scrum está muy orientada al equipo: La velocidad y el burn-down son elementos a nivel de esta agrupación. Las personas son controladas por el mismo equipo de manera secundaria. Si en cada daily-scrum, se ve una persona que no avanza, hay motivos y datos para que el resto de personas le ayuden o le den un toque, pero el foco está puesto en el equipo.
Ya decía Alistair Cockburn que construir software es un juego cooperativo, que sin equipo no hay juego, o al menos no hay juego satisfactorio. Lean nos habla de la calidad en integridad conceptual, que se note que la calidad del producto por que aflora la integridad del equipo que lo realiza.
Ahora me pregunto yo cómo realizar métricas para evaluar el desempeño de las personas... por qué, ¿es necesario en un ambiente ágil? Las personas que no "funcionen" serán rápidamente detectadas por los equipos y no las querrán con ellos. ¿hay mejor métrica que esa?
Si las métricas personales dependen de las estimaciones, ratios de cumplimiento de sus tareas,... ¿es posible formar así un equipo con una motivación común? ¿no lo estaremos tensando demasiado? Supongo que debe haber un equilibrio, pero yo desde luego pondría má peso en el equipo. Nadie construye software solo.
En fin, más preguntas para Agile-Spain ;)

Empresas piramidales

Al de arriba le pinchan, canta la canción... y todos intentan hacerle el coro.

Esta es la manera de los que tienen miedo.
Esto debe ser el efecto de la fiebre. Quizás necesite otro chute de Nolotil.

Por qué los programadores se llevan el trozo grande del pastel (sic)

Dice Joel Spolsky que hay que saber ser flexible para cambiar de contexto cuando sea necesario. Critica que en un desarrollo de un proyecto con una metodología ágil, no se fuese capaz de cambiar al programador para algo quizás más importante por no perder un día de éste en ese proyecto. Lo que parece en realidad es falta de comunicación o conocimiento, ¿qué era más importante para la empresa en ese momento? O el desarrollo del nuevo producto, o la atención al problema que ha surgido sin planearlo. Alguien tenía que decidir. En realidad creo que la crítica a las metodologías ágiles en este caso no está bien traida, pues en realidad como afirma al final el problema es del "manager"

But every decision has pros and cons and when I hear a manager who is just talking about the cons without considering the pros, that manager is not doing their job.

Sim embargo lo que más me ha llamado la atención es esta frase:

This Is Why Programmers Get The Big Bucks. The whole reason you gave them Aeron chairs, unlimited M&Ms, free catered lunches, and the kickass computers with the 30" LCDs is so they can deal with new bugs Microsoft introduced in their code by messing up a DLL that used to work.

No cabe duda de que Joel Spolsky sabe cuidar a sus trabajadores, M&Ms ilimitados :) , comidas incluidas, los mejores ordenadores... y lo que de verdad importa, una valoración excepcional del trabajo que realizan sus programadores. Sabe que su trabajo no es fácil, y lo valora. No es el primer comentario en el que Joel da muestras de saber tratar a sus empleados.
Vamos, como aquí por España, lo mismo. ¿alguién quiere seguir siendo programador toda su vida?